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

[Roger Miller]

On Sunday 17 February 2002 18:06, Glynn Clements wrote:

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

To be a little more precise, the program (which I call the "manager") 
contains and maintains an array of structures.  The array contains one 
element that is not associated with a monitor - that is the "null" monitor.  
An additional array element is generated for each monitor that the user 
starts.  The structure contains the name of the monitor, a pointer to a 
unique Cell_head structure and (when it's completed) a pointer to a unique 
environment array.

On startup the contents of the WIND file from the current mapset and the 
current environment string (initially, the contents of $GISRC) are stored and 
pointers to those data are set into the structure for the "null" monitor.

When a new monitor is started the contents of the Cell_head structure and 
environment string are used to initialize the new array entry. 

It isn't possible to use mapset WIND files or multiple $GISRC files because I 
changed the G_get_window() and G__get_window() library functions to read 
window data from the manager.  Only the manager itself normally accesses the 
contents of the WIND file.  Similarly, I changed the G_put_window() function 
so that only the manager can normally write the contents of the WIND file.

Similar changes are necessary to read and manipulate the environment strings. 
That is somewhat more complex because the environment has to be set up before 
the manager can work.

Communications with the manager is signal driven.  The manager maintains two 
open pipes; one for input and one for output.  When the manager receives 
SIGUSR1 it reads a message header from the input pipe.  The message header is 
optionally followed by additional data.  It responds by placing a similar 
message header in its output pipe followed by any additional data if 
necessary.  

I've written several event driven applications before, but not in a Unix 
environment.    The whole thing is at the level of a proposal and at this 
level concepts are more important than details.  If the concept is acceptable 
then I expect that many details will be changed.

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

I'm not suggesting any change to any module.  If the region associated with a 
newly selected monitor is different from the region that was associated with 
a previously selected monitor then the region will be changed by the manager.

This is possible because I modified start.c, stop.c and select.c to notify 
the manager when changes are made.  I think that the change in each case 
required the addition of three lines of code; one to specify a header file, 
one to define the return type of the message, and one to send the message.

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

I haven't had any problem with the r.* commands working well.  The biggest 
problem I am aware of comes from not always being able to tell which monitor 
is selected.

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

I would really rather not change user modules.  I think it is much more 
effective to introduce system behavior.  That opens up a world of new 
possibilities for GRASS.


Roger Miller