hamish_b at yahoo.com
Thu Apr 14 20:29:47 EDT 2011
> The only (in the current development trunk aka GRASS 7)
> exception is the display system, which you cannot really
> interact with from the command line, but it is foreseen to
> change this.
> You might be able to salvage a part of your GUI by using
> the direct rendering option  of the d.* commands to
> render into an image that you can then display within your
> Tcl GUI. Also, see ximgview/wximageview .
Hi, in an effort to simplify ximgview/wximageview/wxpyimageview
startup I've added a little wrapper script in svn-addons called
"d.mon.py". All it really does is save some keystrokes, and is
just a small experiment, but hopefully it makes it clear to
command line users that they won't be abandoned into second-
Remember that grass7 is still just late-alpha-ware feature wise,
even if the code quality is late-beta-ware (mainly due to the
programming talent doing much of the grass7-specific changes
and a culture of discipline), and we are nowhere near final
As Martin commented earlier, at some point there'll probably be
a wxGUI-light with only the map display window and with basic
interactive features. (my vote would be to move the status bar
and toolbars into a right-click menu + HUD -> K.I.S.S.)
With the possible exception of Roger who seems to have written
code around XDRIVER (n.b. I believe Bob Covill maintains a custom
GTK+ GUI too), I would make the point that we are conflating a
few things here.
- command line driven rendering capability (preserved)
- this can either be simply by user preference, classroom
environ where the focus is on analysis not visuals, those
who use GRASS over ssh with tunneled X (like me), etc.
A specific work flow paradigm shall not be imposed on anyone.
- interactive zooming, panning, querying (ToDo, but possible.
Stripped down components of the Map Display wxGUI can be used)
- the actual XDRIVER backend (code replaced but functionality
to remain via other methods, mostly transparent to the user)
So interactive d.where, d.zoom, d.what.* will probably be
replaced by a toolbar or right-click menu, but is that so bad?
My main point is don't confuse XDRIVER going away with command-
line driven GRASS going away. Don't worry, it wont, as there's
plenty of demand for it and if no one else will code it, I will.
Markus N mentioned that GRASS 6 will be maintained >>1 years,
I'd expect longer than that; I'm still happy to backport fixes
to GRASS 5 if anyone finds a terrible bug or sends in a useful
One thing that makes me hesitant about putting too much python
into the grass6 core is the relative volatility of python- it's
still relatively young and is changing a lot (one of my main
machines is python 2.4, and is kept in that historic state for
external work reasons). 5+ years from now when python 3 has taken
over, would grass6 still be able to run on a modern system?
[such as you could do today if you want access to grass5's
no-memory-overhead sites functionality] From a long-term
maintenance perspective ANSI-C and Bourne scripts take very
little effort to keep humming along, year after year.
ps- random comment: I took d.m out for a spin recently, and was
surprised at how good it still was.
More information about the grass-dev