[GRASS5] Directions for next generation UI

[Michael Barton]

This has been an very productive discussion on how to proceed on developing
a new UI for GRASS. A sensible consensus seems to be developing that
includes 3 parallel sets of activities:

1. Make modifications to critical GRASS C-modules that will allow them to be
integrated much better into a new GUI
2. Enhance the current TclTk GUI to encourage and make use of the C-module
modifications and move in a direction of a new GUI look/function.
3. Begin developing one or more prototype next generation GUI¹s for GRASS.

I think this is a very good idea. Here are a few things that might start
this process.

***For step 1, we need to prioritize which modules need to be modified in
what way, and which are the most critical to modify first. Here is my list,
taken from Glynn's recent post. I'm open to suggestions about reprioritizing
or recategorizing.

-Can be used in GUI as is. Interactive terminal use not required. Modify,
but low priority:

display/d.barscale (accepts screen coordinate input)
display/d.geodesic (accepts coordinate input)
display/d.legend (accepts screen coordinate input)
display/d.path (accepts screen coordinate input)
display/d.rhumbline (accepts coordinate input)
display/d.text.freetype (accepts screen coordinate input)
display/d.what.rast (r.what can be used by GUI)
raster/r.profile (accepts coordinate input)


-Function probably absorbed into GUI. Won't be needed eventually. No need to
modify:

display/d.measure
display/d.where
display/d.zoom


-Needs to be modified to be used in GUI. High priority:

display/d.what.vect (need version like r.what that accepts coordinate input)
display/d.profile (needs to accept coordinate input)
display/d.rast.edit (needs to accept coordinate input)
raster/r.le/r.le.setup
lib/display

Enhance png driver and g.pnmcomp so that they can be used in new display
monitor.

display/d.nviz (needs to read maps in layer tree and more)


-Need GUI versions. May require special widget creation. High priority but
not sure what to do immediately.

raster/r.digit
vector/v.digit (merge r.digit and v.digit?)

imagery/i.ask (what is this?)
imagery/i.class
imagery/i.ortho.photo/photo.2image
imagery/i.ortho.photo/photo.2target
imagery/i.points
imagery/i.vpoints (merge i.points and v.points = i.points3)


***For step 2, we can do the following in TclTk. I'm happy to see what I can
do, but will need help.

Implement as much as possible of look/functionality of new UI design specs
in TclTk to accustom GRASS users to new UI.

Try to implement Glynn's idea about using pnm files and TclTk Canvases, to
move towards new display monitor. (This seems to be a good direction for Qt
also, at least)

Get all of GRASS on all platforms to the same version of TclTk. What about
8.4.10 with expanded widget set (e.g., incl. iwidgets, tclsqlite, etc.)?
This would require some update of NVIZ I think.

I posted the 1st draft UI design specs on my website for people to read and
comment on. Crischan and Trevor have already made some excellent comments.
Please feel free to view and comment. This would be better on a WIKI site.
I'm registered on the GRASS WIKI. Can I make a new 'area'? Or do I have to
ask someone about this?
<http://www.public.asu.edu/~cmbarton/files/grass_ui/UI_design_060102.tgz>


***For set 3, Crischan Wygoda has started on a Qt prototype that people can
try out <http://crischan.net/q1>. It already has some very nice features
that would dovetail with the efforts and specs above. Bob Covill has started
a GTK prototype. I don't propose a 'competition'. We should systematicallly
evaluate the developing prototypes as to functionality, maintainability, and
conformance with design specs over the next month or so.



How does this sound for a way to proceed?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton