[GRASS5] Directions for next generation UI

[Glynn Clements]

Michael Barton wrote:

> 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?

To get the necessary mouse events:

	bind $canvas <ButtonPress-1> {...}
	bind $canvas <Motion> {...}
	bind $canvas <ButtonRelease-1> {...}

The rest of the code would look substantially like the programs which
are being replaced.

> > [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?

	out = if(abs(x()-$x)<ewres()/2 && abs(y()-$y)<nsres()/2,$val,in)

> > 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.

My point is that the user can always just use multiple monitors
instead of multiple frames on a single monitor. The concept of frames
pre-dates X, when you only had one "monitor" (the graphic terminal).

> >> 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?

Currently, no. Is there any advantage to skipping that step?

> > 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=  ?

"d.mon select=..." changes the MONITOR setting in $GISRC, which
affects any programs run in the current session. The environment
variable MONITOR_OVERRIDE can be set on a per-process basis. E.g. if
d.m does "set $env(MONITOR_OVERRIDE) PNG", any d.* commands which it
runs will automatically use the PNG driver, while d.* commands run by
the user from the command line will use the active monitor.

Essentially, using MONITOR_OVERRIDE means that the user can use the
command line concurrently with d.m, without conflicts related to the
active monitor setting.

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