[GRASS-dev] d.histogram: x axis ticks labels fixed

[Michael Barton]

On Jan 30, 2008, at 8:37 AM, Moritz Lennert wrote:

>> The issue isn't one of C versus Python. It's one of being able to run
>> a command to generate a PNG/PS/PDF/etc file on a server versus only
>> being able to generate graphics on a desktop system which is capable
>> of running a GUI.
>> It should be possible to use GRASS in a web application (whether CGI
>> or AJAX or whatever), i.e. in a context where "import wx" is going to
>> fail because there are no X libraries and/or no X display to connect
>> to.
>> IOW, using Python is fine; using libraries which require X (or
>> Windows' GDI etc) isn't.
>> IMHO, it's okay to use cairo, as the dependence upon X libraries is a
>> build-time dependency (you can compile a version which only supports
>> the PNG/PS/PDF file backends), and dependence upon an X display is a
>> run-time dependency (it only needs a display to create an X drawing
>> "surface").
>> OTOH, wxWidgets won't run without a display (AFAICT), even if you  
>> only
>> wanted to render into an image then save it to a file.
>
> That's why I propose to try to code those functions which create  
> histograms, profiles, etc, separating the drawing from the display,  
> i.e.  a function which draws a histogram to a given backend which  
> can either be the GUI or a file. Thus we can use the same command  
> with the same parameters in the GUI and on the command line. This  
> means that these functions should be written as separate scripts  
> which can be called from the GUI and not be integrated the way the  
> seem to be now.
>
> But maybe I'm misunderstanding the whole functioning of wxgrass ...

In some cases this is very doable. In others it would require either  
maintaining 2 parallel modules--one for the GUI and a stripped down  
one for the CLI--or crippling potential abilities of a feature in the  
GUI. I'm reluctant to commit to either of these options. Probably the  
most realistic way to have the best of both worlds as much as  
possible, would be to code complex display functions as a series of  
small, function-limited 'modules' that could be chained together from  
the command line or in the GUI. This is is perhaps more easily doable  
in Python with its structure of classes and methods.

Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>