[GRASSLIST:3161] Re: [GRASS5] Re: Grass GUI

[Glynn Clements]

Roger Miller wrote:

> > > It includes changes to a small number of library functions that allows
> > > more flexibility.  It arranges for G_get_window and other window
> > > functions to always provide information about the window settings of the
> > > currently selected monitor, not from the database WIND files.
> >
> > How does it handle the case where no monitors are running?
> 
> It uses a "nulll" monitor.

A monitor which does nothing but maintain pads? Why not use a file?

> The first monitor that is started inherits it's 
> window setting from the null monitor.  All subsequent monitors inherit their 
> window settings from the currently selected monitor. 
> 
> > Also, I'm not sure what this change would enable. You still can't have
> > multiple sessions using the same mapset directory due to the lack of
> > any finer-grained locking.
> 
> The proposal isn't intended to allow multiple simultaneous access to a single 
> mapset.  It is intended to allow a single user to use multiple monitors to 
> access two or more mapsets within one session, and to use two or more 
> different window settings simultaneously, even while working in one mapset. 

So, basically you're suggesting that "d.mon select=..." should
automatically switch the region?

This might be a good idea for interactive sessions which are primarily
used for displaying data, but probably isn't so good for other uses. 
Personally, I'm not too keen on the idea of the r.* commands using a
different region depending upon which monitor (and which frame) is
current.

It might be better to add functionality to mon.select, and/or
g.region. E.g. add a "monitor=" option to g.region and have mon.select
use that.

> > If the locking issue were solved, the simplest way to support multiple
> > sessions on a single mapset would be to merge the data in the WIND
> > files with most of the data in $GISRC into a "session" file.
> 
> The proposal is intended to do that, but it uses virtual memory instead of 
> creating a file.  I'm not sure that really solves any locking issues, because 
> ultimately the session settings need to be saved back to the WIND file.
> 
> Improved locking is an issue that I think GRASS needs to address eventually.  
> My proposal does not address it.  One possible approach would give the user 
> read-write access to anything in one mapset, but read only access in 
> everything else.

Well, that's largely how things work at the moment. Input maps can
generally be read from any mapset, but output maps are written to the
current mapset.

> > However, note that there is an inherent tension between having
> > multiple sessions on a single mapset and remembering a mapset's region
> > between sessions.
> 
> Yes, that's a problem.

Well, if the region is stored in the session file, an obvious solution
is to keep the session files around so that they can be resumed.

> > > The final capability I
> > > intended to add before I presented the program allows each monitor to be
> > > associated with an entirely different GIS environment.  That allows a
> > > user to display and work with data from more than one mapset and more
> > > than one database location at the same time.
> >
> > AFAICT, the only thing that imposes a "one session per user" limit is
> > the way that $GISRC is managed. You can have multiple sessions,
> > provided that you create a new $GISRC file for each one.
> 
> I don't think that one user running multiple sessions is a better
> alternative.

It isn't meant to be an alternative; the "one session per user"
limitation should be removed regardless. The "one session per mapset"
issue is harder to resolve. It would be easier if the lowest level of
the directory layout were switched, so that each map was a
self-contained directory. I.e. instead of:

	cell/foo
	cellhd/foo
	cell_misc/foo/*

	cell/bar
	cellhd/bar
	cell_misc/bar/*

you would have:

	foo/cell
	foo/cellhd
	foo/cell_misc/*

	bar/cell
	bar/cellhd
	bar/cell_misc/*

There's also the fact that the current directory hierarchy of
$GISDBASE/$LOCATION_NAME/$MAPSET requires that $GISDBASE is
world-writable (so that users can create new locations) and that each
location directory is also world-writable (so that users can create
new mapsets).

As I see it, there are many alternative usage mechanisms, including:

	+ Interactive command-line session
	+ GUI
	+ Scripts
	+ Web application

My main point is that support for any particular mechanism shouldn't
be at the expense of others. Currently, anything other than an
interactive command-line session is complicated by the inbuilt
orientation towards that particular mechanism.

BTW, Eric's change to the monitor socket path potentially makes
matters worse for web applications. Whereas monitor names were tied to
a mapset (i.e. you used to be able to have multiple instances of
"d.mon start=PNG", provided that each had a different mapset), now
they are tied to a UID. So now you would have to "allocate" monitor
names.

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