[GRASS5] Directions for next generation UI

Radim Blazek radim.blazek at gmail.com
Tue Jan 3 06:10:34 EST 2006

On 1/3/06, Michael Barton <michael.barton at asu.edu> wrote:
> 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.

Just a note for users and interested developers. Development of GRASS plugin
for QGIS continues and it will continue in future even if it is not mentioned
in Michael's list. Users' response is very positive (QGIS IRC).

QGIS 0.8 will bring:
- location/mapset creation wizard
- mapset can be opened/closed from QGIS
- graphical inteface for mapcalc
- many new tools in toolbox (import,network,interactive extraction,...)
- GRASS shell


> 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
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5

More information about the grass-dev mailing list