[GRASS5] Directions for next generation UI

[Michael Barton]

> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Wed, 4 Jan 2006 18:44: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:
> 
>>>> 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...
> 
> The commands in question are those which should be integrated into the
> GUI, so inevitably they need to be written for the specific GUI
> implementation.
> 
> If there is a substantial part of any of the commands which isn't tied
> to a particular GUI, that can be made a stand-alone program (e.g. the
> bulk of d.what.rast is provided by r.what; you just need to obtain the
> coordinates with the mouse then run r.what).
> 
> One task which will need to be done for several of the built-in
> commands is converting a "screen" (x,y) position to geographic
> coordinates.
> 
> This should probably be a function in the GUI program itself, so that
> you can (efficiently) provide a continuous display of the geographic
> coordinates of the mouse cursor (you wouldn't want to have to run an
> external program every time the mouse moves).

Right. I don't know how to do this in TclTk, but if done, then a zoom
function, for example, could be built by simply using the mouse geographic
coordinates to send new extents to g.region.

> 
>>>>> [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.
> 
> That's a very different task to what r.reclass does. r.reclass
> constructs a reclass table, leaving the raster data untouched. A
> program to modify the actual raster data wouldn't have anything
> significant in common with r.reclass.
> 

So a reclass table by coordinate rather than cat isn't feasible? What about
doing it for r.recode. I only mention these two modules because they accept
file input of a list of parameters for changing a map.

>>>>> 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.
> 
> That's arguably something that's better left to higher-level tools.
> E.g. if you implemented it in d.m, you would be able to move the
> frames around with the mouse, toggle them on or off etc, without
> having to redraw everything.
> 
> Also, if you were producing illustrations for publication, you would
> normally want a PostScript/PDF file where vector graphics, text etc
> were actually stored as such, rather than having been rasterised.
> PostScript's text and vector rendering capabilities go far beyond
> anything that GRASS' display architecture will ever provide. For that,
> you would want each "component" (raster, legend, heading etc) as a
> separate entity rather than all rendered into one raster image.
> 
> [BTW, the Tcl/Tk canvas widget has a built-in "postscript" command to
> generate a PostScript representation of the contents of the canvas.]
> 

I agree that this is better, just that it's additional programming. In the
interim, d.frame remains useable because you don't have to use a mouse (with
terminal interaction) to define the frames.

>>>>>> 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.
> 
> Reading/writing 1MB of data should be so fast you don't even notice
> it. Converting the PPM file into whatever Tk uses internally may take
> some time, but that isn't a step that can be circumvented. I would
> expect the slowest step to be d.rast, which is slow whatever driver
> you use.
> 

OK, I won't worry about it


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