[GRASS5] Initial window state
rgrmill at rt66.com
Thu Jul 18 19:02:26 EDT 2002
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
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
> AFAICT, the main situation where users are tripped up by the region
> mechanism is in importing rasters which lack georeferencing
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.
More information about the grass-dev