[GRASS5] Initial window state

[Roger Miller]

Thanks for responding, Glynn.

Glynn Clements wrote:

> Why only d.* commands? Many commands use the region settings.

This is a start-up problem that has (to my knowledge) only been reported 
for the display.

> If some kind of automatic region setting is necessary, it might be
> better to do it from within e.g. G_open_cell_old(). But then, what if
> a program queries the region before opening any maps? At least one
> program (I forget which) queries the region before even calling
> G_parser(), in order to initialise some defaults.

With the changes I described the region is still initialized as it is now 
based on the contents of the WIND file, but the initialization flag is unset. 
Any module that accesses the region setting (which I think covers most user 
modules) will set the initialization flag.  Once the flag is set GRASS will 
work exactly as it does now.

The region is set from the file header data only if the region data have 
not been accessed before a file is displayed.  In most cases that means 
that the region is set from the file data only if the map display is the 
first operation performed in a session.

> Also, the "region ... read by the user" test would have to be
> implemented in g.region etc. Many programs call G_get_region() before
> opening maps, so having the test in G_get_region() would nullify the
> behaviour.

The behavior *should* be nullified in that case.  If any analysis is 
performed using the initial region then the display modules should not 
automatically reset the region from the file header.  If the region were 
reset it could produce misleading results.  The analysis would have been 
performed for a region different from the region that is displayed.

> Personally, I think that this "solution" is going in the wrong
> direction. I feel that GRASS needs less "magic" behaviour rather than
> more. For interactive use, GRASS *needs* a UI, not lots of "useful for
> interactive use" behaviour wedged into various places.

This helps solve a widespread complaint.  I don't think that fixing 
complaints is the wrong way to go.  

GRASS has a UI and that UI that requires frequent, repetitive execution of 
several user commands.  I would hope to reduce the amount of annoying and 
cumbersome repetition.  None of this is "magic".  It's an attempt to 
create a more evolved system behavior.

I agree that this isn't the best way to do things.  Unless GRASS has a 
persistent central manager then the system behavior has to be built up 
bit by bit in a fairly disorganized fashion.  I don't think that's a good 
way to do it, and that's why I use a manager program.  The manager 
centralizes the system and makes a lot of further developments look 
relatively easy.

> AFAICT, the main situation where users are tripped up by the region
> mechanism is in importing rasters which lack georeferencing
> information.

I get blank screen behavior in a number of different ways, but that 
behavior is a fairly minor problem to an experienced user.  I think the 
main case where the blank screen result is a problem is when a new user is 
forced to set the map region when they first start GRASS.  Most people 
probably don't know the area they need to cover and they don't have any basis 
for understanding the significance of the initial region settings.  Often the 
user's initial window settings are incorrect or just useless and the first 
map they try to display produces a blank screen.  When that happens 
GRASS looks broken; in fact one could say that GRASS *is* broken because 
it lets that happen.

If the region can be set from a map, then the startup procedure can be 
rewritten so that a new user doesn't have to provide useful settings.  
Reasonable defaults can be used instead.


Roger Miller