Roger,
Thank you for the detailed explanation. I can imagine that such a
long-grown home made GUI gives you a productivity which will be very
difficult to reproduce quickly with any other tool.
Some tentative comments to your explanations:
On 14/04/11 15:16, Roger Miller wrote:
First is that the GUI should be organized and visually simple, not
confusing to the eye and it should offer only a few choices at any time.
If you're already accustomed to looking at your GUI -- I'm not -- then
you probably won't get confused by it's visual presentation.
Yes, this is obviously very subjective.
Second is that no capability should be added to the GUI unless it can be
made simpler and/or faster than the command line operation.
In a certain way this is the same philosophy as with the mainstream
GRASS GUI: most of the GUI is just an automatically created "graphical
wrapper" around the command line. Only those tools that make sense only
in a graphical environment are implement directly in the GUI. The rule
has (almost) always been: everything you can do in the GUI, you should
be able to do in the command line, unless this doesn't make any sense.
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].
[1] http://grass.osgeo.org/grass70/manuals/html70_user/cairodriver.html
("GRASS_RENDER_IMMEDIATE")
[2] http://trac.osgeo.org/grass/browser/grass/trunk/visualization
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
