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