[GRASS5] Some thoughts

[Glynn Clements]

Roger Miller wrote:

> One of the changes introduced between beta11 and pre2 brought to mind
> something I've been thinking about for a while.  In the beta11 release I
> was able to start a monitor, exit from GRASS and restart GRASS to get to a
> different locations, then continue using the same monitor.  Now I can't.  
> When I end one GRASS session the monitor that was associated with it can
> no longer be used to display output from the new location, or even from
> the original location.  That requires that I manually stop all monitors
> before I exit, and restart monitors when I reenter -- things that were
> unnecessary while I was still using beta11.

This seems to work in pre3. Eric moved the monitor sockets from
$LOCATION/.tmp to /tmp/grass-<user>.

AFAIK, the socket had always been in $LOCATION/.tmp prior to that. I
presume that you were using FIFOs with beta11 (they live in
$GISBASE/dev), but sockets with pre2.

There might be problems associated with the redraw-upon-resize feature
which has since been introduced to the monitor. Any commands which are
run by the monitor to perform the redraw will inherit their
environment from the monitor, which in turn inherits its environment
from the session in which it was started.

The most important variables (GISBASE, LOCATION etc) should be read
from $GISRC, but anything which is read from the environment could
cause problems.

> This is only one example of a fairly pervasive problem in GRASS; simple
> operations often require multiple manual steps.  Multiple manual steps
> give the user some flexibility that he might not otherwise have, but they
> also create a steep learning curve and build barriers for new GRASS
> users.
> 
> Different problems require different solutions, but I think there might be
> one solution that can help smooth through a lot of different problems.
> 
> Would it be possible (or practical) for GRASS to incorporate a user-level
> daemon that manages the GRASS monitors and user environment?  Initially
> the daemon could make sure that monitors are stopped when sessions end and
> perform simple mechanical operations like erasing the active monitor when
> the user resets the region.  Eventually it could be used to serve all of
> the user's state variables.  It would be a step toward building a more
> integrated GIS and help create a more dynamic multi-user system.

There are some problems with the existing "user interface". The first
is that it is fairly primitive. The second is that it gets in the way
of building a better user interface.

Personally, I would like to see a more layered approach. All of the
underlying commands would be stripped of any behaviour which is
oriented towards the existing interface. This includes things like
prompting for input, modifying defaults according to monitor/region
settings, and most of the "session" behaviour.

Once that was done, it would be more straightforward to build decent
interfaces on top of the core functionality. The problem is that, in
the meantime, it would become even less friendly for interactive use.

-- 
Glynn Clements <glynn.clements at virgin.net>