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

[Moritz Lennert]

On 30/01/08 16:19, Glynn Clements wrote:
> Moritz Lennert wrote:
> 
>>> Understood. These python utilities draw to Python canvases, and so 
>>> normally need the GUI to run. It may be possible for them to output to a 
>>> graphic file too. But they are designed to work in a GUI environment 
>>> rather than a command line environment.
>> http://matplotlib.sourceforge.net/faq.html#BATCHMODE
>>
>>
>>> I don't advocate ditching d.histogram. In fact, the *easiest* thing from 
>>> my standpoint, would be to have a sophisticated and slick C-graphing  
>>> module that I just had to call as a command and presto it creates a 
>>> graphic file that I can pop into a canvas. But I have some understand of 
>>> the complexity of writing this in C or anything else. That's why to use 
>>> high level graphing tools to do this.
>> We do have some C-code which exists. It's just a question of whether we 
>> think that someone will take the time for updating that, or whether we 
>> should profit of the efforts done for the GUI to just have the same 
>> functions also available on the command line (with the additional 
>> advantage of consistency). If python is a required dependency anyhow, I 
>> don't have any religion about a module absolutely having to be in C if 
>> the python version is just as good.
> 
> 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 ...

Moritz