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