[GRASS5] Some thoughts

[Roger Miller]

Folks,

I recently updated my GRASS installation from beta11 to pre2.  There were
a lot of great changes made between those two releases and I expect even
more with the new pre3 release.  My congratulations go out to Markus and
all the rest of you for producing a steadily improving and ever more
useful GIS.

I've contributed a little source to GRASS, but mostly I am a GRASS user,
and I have some comments mostly from the user's perspective.  I use linux
and typically work off the command line.  Forgive me if any of my
following comments are unique to those conditions or have been fixed in
later releases.

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


Roger Miller
Lee Wilson and Associates