[GRASS-dev] updates to region setting and display rendering in GIS Manager

[Glynn Clements]

Michael Barton wrote:

> I just committed a set of updates to the cvs that should enhance region
> management and display rendering times in the GIS Manager.

> -Setting the region with g.region will affect the computational
> region/geometry of any GRASS command run from the menu or command line in
> the same way, no matter how g.region is started. It will have no automatic
> effects on any display.
> 
> -Except for the display in the TclTk canvases of the GIS Manager, all GRASS
> commands will use the same region information, whether started from the
> command line or menu.

I'm still not sure whether this is a good thing. Apart from anything
else, it means that you need to be careful about running background
jobs from the shell, as any region changes within the GUI will affect
them.

This isn't a problem for monolithic C programs, which read the WIND
(etc) file once at startup, but it could be a problem for scripts or C
programs which run other GRASS modules via system/popen. Each child
will read the WIND file itself, potentially getting settings which
differ from the parent. I'm wondering if G_get_window() should export
the setting to GRASS_REGION so that any children automatically get the
same region.

My inclination would have been to make this an option: allow gis.m's
computational region to either mirror the shell's version (i.e. leave
WIND_OVERRIDE unset so that the WIND file is used) or to be separate
(set WIND_OVERRIDE to a private saved region). For the latter case,
you would have specific commands to import/export the gis.m region
from/to the WIND file.

If gis.m uses GRASS_REGION as the sole method for forcing specific
regions, then manually setting WIND_OVERRIDE to the name of a saved
region before starting gis.m will solve this. However, if gis.m uses
WIND_OVERRIDE for any reason, it should set it back to the value which
it had at startup rather than "unset"ting it.

OTOH, whatever gis.m does, the user can always force the shell to use
a separate region by setting WIND_OVERRIDE manually.

One final point: using WIND_OVERRIDE (instead of GRASS_REGION) for the
display regions (i.e. giving each display its own saved region) would
have the advantage that the user can directly access those regions
from the shell, either using WIND_OVERRIDE= or "g.region region=".

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