[GRASS5] Directions for next generation UI

[Glynn Clements]

Michael Barton wrote:

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

The arithmetic is all in lib/display/cnversions.c.

For the purposes of d.m, you should only need the D and U coordinate
systems, not the A system.

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

Yep. Except that it might be useful to have a WIND_OVERRIDE variable
so that d.m could avoid modifying the WIND file. This would make it
easier to have multiple views with different zoom/pan, as well as
allowing you to run commands in the background without worrying about
the WIND file being changed.

The persistent state provided by $GISRC, the WIND file, monitor pads
etc, is useful for command-line usage, where you don't want to have to
pass a lot of parameters to every command, but are unnecessary (and an
obstacle) for a GUI application, which can maintain its own state, and
pass explicit settings to each command.

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

r.recode is a better fit, as it actually generates a new raster array. 
But that's a side issue; everyone seems to have managed to get by so
far without an r.edit module having been available.

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

After mouse input, "pads" (property lists used to store information
within the driver) would be the next thing to go. As frames are
essentially just rectangles stored in an pad, frames would go too.

[The reason for eliminating pads is that they amount to state which
persists between display commands; persistent state belongs in the GUI
alone. Ultimately, the display architecture should be nothing more
than a library which can be used by display commands to generate
graphics.]

With regard to adding display views to d.m, it would be worth
organising code in such a way that views can exist anywhere within the
widget hierarchy, rather than e.g. assuming a 1:1 correspondence
between toplevel windows and display views.

You don't actually need to provide the functionality to create
arbitrary layouts of views, just ensure that any code which maintains
a view doesn't make unwarranted assumptions about its position in the
widget hierarchy.

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