[GRASS5] Some thoughts

GRASS GRASS developer
1

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

2

Roger Miller wrote:

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 seems to work in pre3. Eric moved the monitor sockets from
$LOCATION/.tmp to /tmp/grass-<user>.

AFAIK, the socket had always been in $LOCATION/.tmp prior to that. I
presume that you were using FIFOs with beta11 (they live in
$GISBASE/dev), but sockets with pre2.

There might be problems associated with the redraw-upon-resize feature
which has since been introduced to the monitor. Any commands which are
run by the monitor to perform the redraw will inherit their
environment from the monitor, which in turn inherits its environment
from the session in which it was started.

The most important variables (GISBASE, LOCATION etc) should be read
from $GISRC, but anything which is read from the environment could
cause problems.

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.

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@virgin.net>

3

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@virgin.net>

Markus

4

Markus Neteler wrote:

a layered XDRIVER is already there in head:

That wasn't what I meant by "layered". I was referring to the overall
architecture of the system.

On the bottom layer, you have libraries.

On the layer above that, you would have all of the various
command-line tools, which wouldn't attempt user interaction, or rely
upon being part of some session.

The topmost layer would provide an interactive environment (as well as
non-interactive environments, e.g. GRASSlinks).

Right now, implementing a decent GUI isn't realistic possibility, due
to the number of programs which, in one way or another, assume that
they are interacting directly with the user via a terminal and/or the
R_get_location_with_* functions, effectively eliminiating the
possibility of controlling them from some other program.

In order to be able to implement a proper GUI (as well as things like
a web interface), the core programs have to cease using G_ask_*,
R_get_location_with_*, stdin, stdout, stderr, etc. Instead, they need
to just parse the command line, read data, perform computation, write
data, and exit.

In short, the programs have to stop behaving like stand-alone programs
and start behaving like modules of a larger system. In order for that
larger system to provide a decent level usability, it needs complete
control over what interaction occurs and when; which implies that the
individual modules don't get to perform interaction of their own
volition.

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

5

On Thu, Jan 17, 2002 at 09:17:19PM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> a layered XDRIVER is already there in head:

That wasn't what I meant by "layered". I was referring to the overall
architecture of the system.

Ah - yes! Funny, as a result from the Trento meeting I already
wanted to post something into this direction.

On the bottom layer, you have libraries.

On the layer above that, you would have all of the various
command-line tools, which wouldn't attempt user interaction, or rely
upon being part of some session.

The topmost layer would provide an interactive environment (as well as
non-interactive environments, e.g. GRASSlinks).

I would even propose two different views on above model:

1. the technical model: circular layers of GRASS around the CORE-GRASS
    (libraries), the command-line tools, the GUI (as you described above)
2. the user model: Most advanced users in the inner circle, average
    users around. This may sound ridiculous, but is rather complex.

Some thoughts:

ad 1.: Especially for the 5.1 development we should first focus on
        CORE-GRASS, to get it stable and reliable, with test environment
        etc. In my opinion it is very important to break up the system
        into packages, such as CORE, BASE, HYDRO, whatever we call it
        to be able to have the core system and plug-ins. This should be
        easier to maintain and easier to release. The users can only
        download packages of their interest (to run it even on a
        hand-held)

ad 2.: As GRASS is a general purpose GIS, we have a quite heterogenous
        user community with different expectations. We want to provide
        tools for advanced users who want to perform complex tasks as
        well as interest the wide "average" user community who maybe
        just wants to import data and make a map. At least newcomers
        have some problems to get familiar with the system. When picking
        up the people at *their* level of knowledge, we may get many more
        users. The psychological threshold to work with GRASS may be to
        high for lots of newcomers. But: There must remain the advanced
        level such as command line to omit the "click-click" GIS :slight_smile:
        In summary: when thinking of the different users, we need to
        address their different needs.

Right now, implementing a decent GUI isn't realistic possibility, due
to the number of programs which, in one way or another, assume that
they are interacting directly with the user via a terminal and/or the
R_get_location_with_* functions, effectively eliminiating the
possibility of controlling them from some other program.

In order to be able to implement a proper GUI (as well as things like
a web interface), the core programs have to cease using G_ask_*,
R_get_location_with_*, stdin, stdout, stderr, etc. Instead, they need
to just parse the command line, read data, perform computation, write
data, and exit.

In short, the programs have to stop behaving like stand-alone programs
and start behaving like modules of a larger system. In order for that
larger system to provide a decent level usability, it needs complete
control over what interaction occurs and when; which implies that the
individual modules don't get to perform interaction of their own
volition.

Maybe yes for above, but we should somewhat keep the modular character
with low memory overhead etc. Probably a question of implementation.

Just some more thoughts,

Markus