[GRASS5] Directions for next generation UI

[Michael Barton]

I managed to get a display into a TclTk canvas. It's an ugly hack, but it
works. I can try to refine it.

I can put display management buttons across each monitor window top, but it
isn't much help unless there are display management tools to go  with them
(mainly zoom, pan, and query). Any thoughts about how to implement these in
TclTk? Or is  this where we need to update versions of d.zoom, d.what.x,
etc?


> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Tue, 3 Jan 2006 17:11:06 +0000
> To: Michael Barton <michael.barton at asu.edu>
> Cc: grass5 <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Directions for next generation UI
> 
> 
> Michael Barton wrote:
> 
>> -Needs to be modified to be used in GUI. High priority:
> 
>> display/d.rast.edit (needs to accept coordinate input)
> 
> If you're referring to a program to allow you to modify raster cells
> (i.e. map[x,y]=val) from the command-line, I think that's really a
> completely different module (r.edit?).

Actually there is no r.edit. D.rast.edit is the module that let's you modify
cat values of individual cells, chosen with a mouse. It'd kind of misnamed.
R.edit would be more appropriate. If it took an x,y,val, I guess it could be
used in a GUI to the extent that any other of these modules could be. Though
a GUI version would be nicer.

> 
> [Doing this for individual cells is easy enough using r.mapcalc, but a
> version which takes a file of x,y,val records might be useful.]

How do you do this from r.mapcalc when you need x and y to be geographic
coordinates?

> 
> The existing d.rast.edit really falls into the "needs GUI version"
> category, IMHO.
> 
>> lib/display
> 
> Usage of R_get_location_with_* in lib/display comes down to three
> functions:
> 
> int get_win_w_mouse() (get_win.c)
> 
> Prompt the user to select a rectangular region using the mouse.
> Used by: d.frame
> 
> int ident_win() (ident_win.c)
> 
> Select a "window" (aka "frame", as in d.frame) using the mouse.
> Used by: d.frame
> 
> D_popup() (popup.c)
> 
> Create a popup menu on the monitor, return index of selected entry
> Used by: d.rast.edit, d.zoom
> 
> Regarding the first two, do we really need "frames"? I assume that
> they date back to the use of graphics terminals (Tektronix 4105 etc)
> before the advent of windowing systems meant that you could have
> multiple monitor windows.

D.frame is the only module that permits multi-map 'layouts' in GRASS (e.g.,
inset maps). It is kind of clunky, but pretty useful. It would be better to
have a nice GUI layout facility (with rulers, snap-to grids, etc) that works
with multiple monitors (ala Trevor's suggestion), but that is quite a bit of
work I suspect.

> 
> Which modules still use them? How many of those /don't/ fall into the
> category of "needs GUI version"?
> 
> Regarding the third, d.rast.edit needs a standalone GUI version, and
> d.zoom should be an integral feature of d.m.

See opening question.

> 
>> Enhance png driver and g.pnmcomp so that they can be used in new display
>> monitor.
> 
> I don't think that any enhancements are strictly necessary (although
> some might be useful).

This was following your suggestion. But you are correct in that they work OK
as is. Is there any way to bypass the need to write the display to a disk
file, then read it from file into a canvas or other monitor widget?

> 
> BTW, you use the environment variable MONITOR_OVERRIDE to force a
> display command to use a specific monitor regardless of the MONITOR
> setting in $GISRC.
> 

Could you explain this. How is it different from d.mon select=  ?

>> -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?)
> 
> It appears to be a "map selector" dialog using the monitor. AFAICT,
> it's only used by d.ask. IOW, similar to D_popup().
> 
>> 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 think that we should make a reasonable effort to support all recent
> (8.x) versions of Tcl/Tk, without requiring too many add-ons. We need
> to accept that compatibility issues may restrict which versions of
> Tcl/Tk are suitable for NVIZ on some platforms. d.m should work with
> whatever version the user needs to use for NVIZ.

We should at least be able to package an updated bwidgets with GRASS if
needed. I don't know what iwidgets needs. Tclsqlite would help if we make
sqlite the default dbms in the future. But by that time, we may have moved
on to a new UI platform.

> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>


__________________________________________
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