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

[Glynn Clements]

Michael Barton 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.

That's reasonable enough, but the code has to be structured in such a
way that the higher-level components interface to some form of
externally-supplied driver for the actual drawing.

That's where MatPlotLib appears to fall down: the choice of backends
is hard-coded into the library, so there's no way practical way to
redirect the output to the GRASS display system.

Unless the backend interface is made part of the public API, the only
practical way that we can use MatPlotLib is to bundle our own version
with a backend for the GRASS display system.

-- 
Glynn Clements <glynn at gclements.plus.com>