[GRASS5] Directions for next generation UI

Michael Barton michael.barton at asu.edu
Tue Jan 3 15:50:16 EST 2006


As Gary pointed out, this will be a benefit to GRASS users, others, and for
further developing GRASS.

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



> From: Radim Blazek <radim.blazek at gmail.com>
> Date: Tue, 03 Jan 2006 12:10:34 +0100
> To: Michael Barton <michael.barton at asu.edu>
> Cc: grass5 <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Directions for next generation UI
> 
> 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
>     http://mpa.itc.it/radim/qgis/newmapset4.png
>     http://qgis.org/flash/flashwrapper.php?filename=grass_plugin1.swf
> - mapset can be opened/closed from QGIS
> - graphical inteface for mapcalc
>     http://mpa.itc.it/radim/qgis/mapcalc.png
> - many new tools in toolbox (import,network,interactive extraction,...)
> - GRASS shell
>     http://mpa.itc.it/radim/qgis/shell1.png
> 
> Radim
> 
>> 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