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

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

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

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

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