Moritz wrote:
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 [1] of the d.* commands to
render into an image that you can then display within your
Tcl GUI. Also, see ximgview/wximageview [2].
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-
class. 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/display/d.mon
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
feature freeze.
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
patch. ...aside:
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.
don't panic,
Hamish
ps- random comment: I took d.m out for a spin recently, and was
surprised at how good it still was.