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
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
