[GRASSLIST:3161] Re: [GRASS5] Re: Grass GUI
rgrmill at rt66.com
Sun Feb 17 21:25:18 EST 2002
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
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
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
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
> 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.
More information about the grass-dev