[GRASS-user] Region definition in Grass 6.1 (and 6.1 cvs)

[Glynn Clements]

Michael Barton wrote:

> >> but most important: If you zoom in and make some action (for example
> >> r.to.vect) it will affect ONLY on zoomed fragment
> 
> IMPORTANT CLARIFICATION: Region zooming in the display generally ONLY
> affects that display and related tools IN THAT DISPLAY. Most system wide
> commands (e.g., r.to.vect) will respond to the current setting in the WIND
> file, not the dynamic region setting in the display. This is because we are
> trying to avoid having any particular display affect the system-wide WIND
> file. 
> 
> So if you are running a system-wide command (i.e., not tied to a display,
> its toolbar, or its layer tree) you need to make any desired region settings
> via g.region. It doesn't matter whether g.region is run from the command
> line or from a menu selection. Alternatively, you can display the region you
> want, then select 'set WIND file from displayed region' from the menu button
> on the display toolbar. If you just zoom interactively to somewhere in the
> display without setting the WIND file, the region-related effects of a
> system-wide command may not be what you want.
> 
> We may want to think about this more. Would it be better for a system-wide
> command to affect the region set by g.region or the region displayed in a
> particular display? Which display? How to make sure it is what you  want?

The display region certainly shouldn't be stored in the WIND file
(unless the user specifically selects that option). Whether or not the
display region should affect commands run from gis.m is a separate
issue.

Personally, I would say yes. At least, it definitely needs to be
possible to run a command from gis.m using a region other than that
stored in the WIND file. IMHO, the WIND file should be considered a
"legacy" feature, i.e. retained solely for the purpose of backward
compatibility.

gis.m should either use the region of the "active" display, or have
its own concept of "current region" distinct from the WIND file. 
AFAICT, the main issue with the former is choosing a useful notion of
an "active" display.

If each display window had its own copy of the menu bar, this would be
simple; the active display for any command run from the menus would be
the display to which the menu bar was attached.

With a single menu bar, you would need some other way to select the
active display. Using the WM focus isn't sensible, IMHO; depending
upon the WM, switching from a display window to the window containing
the menu bar using e.g. Alt-Tab may result in a different display
window temporarily obtaining the focus.

OTOH, if you don't use the region from an active display, but have a
distinct "current region", there should be an option to indicate this
on the display(s), so that the user isn't surprised when a
newly-created map has different bounds and/or resoltion to the map
they were just looking at.

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