[GRASS-dev] g.mapset calling D_erase() ?

GRASS GIS GRASS GIS developer
1

Hi,

g.mapset calls D_erase(), should it?

Obviously the display will be stale after changing the mapset, but for me
a typical use is to drop into the PERMANENT mapset for a minute to adjust
something (say g.region -s or g.setproj), then back to my normal session.

any thoughts? Should g.mapset be like a soft-reboot of the GIS or a simple call to g.gisenv? Is it worth it to add a flag to g.mapset to skip the D_erase()?

I guess it's a similar issue to GRASS 5 leaving xmons open after the main
program quits.

?,
Hamish

2

Hamish <hamish_b@yahoo.com> writes:

> Hi, g.mapset calls D_erase(), should it?

  My opinion is that it shouldn't.

  I'd say that to ease both the maintenance and learning of GRASS
  the modules should have as less side effects as possible.

> Obviously the display will be stale after changing the mapset, but
> for me a typical use is to drop into the PERMANENT mapset for a
> minute to adjust something (say g.region -s or g.setproj), then back
> to my normal session.

> any thoughts? Should g.mapset be like a soft-reboot of the GIS or a
> simple call to g.gisenv? Is it worth it to add a flag to g.mapset to
> skip the D_erase()?

  Since this behaviour isn't probably relied upon, I think it
  isn't necessary.

> I guess it's a similar issue to GRASS 5 leaving xmons open after the
> main program quits.

> ?, Hamish

3

Hamish wrote:

g.mapset calls D_erase(), should it?

No. Nor should it call any R_* or D_* functions.

Obviously the display will be stale after changing the mapset, but for me
a typical use is to drop into the PERMANENT mapset for a minute to adjust
something (say g.region -s or g.setproj), then back to my normal session.

any thoughts? Should g.mapset be like a soft-reboot of the GIS or a
simple call to g.gisenv? Is it worth it to add a flag to g.mapset to
skip the D_erase()?

Even if the existing behaviour is desirable, it should probably be
implemented by spawning d.erase rather than linking directly against
the raster and display libraries.

BTW, if you run g.mapset with GRASS_RENDER_IMMEDIATE=TRUE, you get a
chunk of libpngdriver boilerplate for each line in etc/monitorcap.
(i.e. it calls R_open_driver() for each monitor; with
GRASS_RENDER_IMMEDIATE=TRUE, R_open_driver() never fails).

Another day, another example of a GRASS module which tries to do
something "clever" and ends up doing something stupid.

--
Glynn Clements <glynn@gclements.plus.com>