[GRASS5] Initial window state

[Roger Miller]

Folks,

New GRASS users often report problems the first time the try to display a map 
because the map either does not fall in the window region or the window 
region is much larger than the active window.   I think this is an 
acknowledged problem, but one that doesn't have a simple solution.

I've fixed this problem in my own installation.  My installation uses a 
management program to coordinate some resources, but I think a similar 
approach could be used to provide the same solution without using the manager.

The idea is that if the user takes no action to read or change the window 
region before a map is displayed then the active window is defined by the 
header data for the map that is displayed.

The process requires a persistent global flag that is initialized to 0 when a 
session starts and is toggled to 1 when the active region has been read or 
written by the user.  The gis environment is the only mechanism I can think 
of that provides such a persistent global variable in a standard GRASS 
installation.  If so, then the variable will have to be written to $GISRC 
each time it is initialized or changed.

The active region is only read and modified by a small number of library 
functions, particularly G_get_window and G_put_window.  These would need a 
one line addition to set the initialization flag to 1 when they are invoked. 

The functions that display maps (d.rast, d.sites, d.vect.*) need to be 
modified so that they check the state of the initialization flag.   If the 
flag is not set then they need to set the active region from the header 
information for the map they display.  Most of the code necessary for that is 
already in the source for g.region.

That's most of the work, but there are two additional changes that I know of 
that need to be made.  The code for mon.select calls D_setup().  That call 
needs to be removed, because D_setup reads the active window and would 
otherwise cause the initialization flag to be set before any map is 
displayed.  D.rast and d.vect call D_setup themselves, so removing the call 
from mon.select doesn't change their behavior.  D.sites does not call D_setup 
and I found it necessary to add a call to D_setup to the main program in 
d.sites.  I also removed several statements from the d.sites main code that 
appear to at least partially duplicate the function of D_setup.

I have not tested d.vect.* or any of the image modules.  I expect that if 
necessary they will take the same simple changes that worked on d.rast, 
d.vect and d.sites.  If changes are not made then those modules probably 
won't be broken, they will just continue to work as they do now.

So far I've found the capability to be useful for more than just beginners.  
It may be possible to invoke that initialization behavior more frequently 
(like each time a monitor is started) and to save on the times it is 
necessary to run g.region.


Roger Miller