[GRASS5] Directions for next generation UI

[Michael Barton]

> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Wed, 4 Jan 2006 14:56:18 +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:
> 
>> 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.

So this means a rewrite of the display management commands to work with
whatever UI platform we use...

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

Yes it would. This might be best added to r.reclass, so that it takes a file
of x,y,val as well as cat=val.


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

The problem is that you can't get saved graphic output that shows multiple
maps, legends, etc. in a set of arranged windows by arranging multiple
monitors. It would be better to do it the way Trevor suggests, but outside
of d.frame, this ability does not exist in GRASS at the moment.


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

It's just a bit faster and saves some space. The png/ppm monitor output runs
1+ Mb. It takes a few seconds to write that out, then more time to read it
in. We're talking seconds, but it still slower than the current display
because it has to write then read.

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

This sounds very handy. I'll remember it.

Michael