[GRASS5] Some thoughts

[Markus Neteler]

On Thu, Jan 17, 2002 at 06:05:37PM +0000, Glynn Clements wrote:
[...]
> > 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.

Hi,
a layered XDRIVER is already there in head:
grass_exp/src.todo/display_driver

It is a layered XDRIVER (now heavily outdated) and d.layers tool.
My correspondence with the author is also stored there. Perhaps
someone picks it up and merges (will require some work!) the code
into the current XDRIVER?
Pierre, the author also started to implement RGB for all display
modules and initial transparency through alpha channels.

Maybe a starting point?

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

Markus