[GRASS5] Platform for next generation UI

[Glynn Clements]

Trevor Wiens wrote:

> > > > + Minimising dependence upon global state (WIND, $GISRC, monitor pads,
> > > > etc).
> > > 
> > > I would expect this would be highly desirable to addressing issues of
> > > having multiple users accessing a single location at one time.
> > 
> > That situation is harder to solve.
> 
> Yes, but wouldn't it be logical to try to solve that at the same time
> since this is a desirable feature and we only need to make the changes
> once?

No. By "harder", I mean "several orders of magnitude harder".

Minimising dependence upon global state is a relatively simple matter
of modifying the functions which query that state to allow the values
to be overriden, so that the global state simply becomes a default.

A concrete example: modifying the functions which read the WIND file
to first check for an environment variable (e.g. WIND_OVERRIDE) and,
if set, read the file to which that variable refers instead. That
would allow the GUI to run commands using a specific region without
having to modify the WIND file (which could interfere with other any
other commands which were running).

[The redraw-on-resize functionality built into XDRIVER involves
something similar; R_open_driver() first checks for the environment
variable MONITOR_OVERRIDE, and only uses the MONITOR setting in $GISRC
if that is unset. This allows a monitor to redraw itself even when it
isn't the active monitor.]

Making it so that multiple commands could safely modify a given mapset
concurrently would require adding fine-grained locking to every
module, including deadlock detection, inheritable locks etc. That is a
vast amount of work just to implement, let alone the design issues.

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