[GRASS-dev] XDRIVER

[Hamish]

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.