[GRASS5] gis.m limitation

GRASS GIS GRASS GIS developer
1

Michael,

On of the short comings with gis.m that I now find is that it is
impossible to zoom to a file with the new interface since shell
commands no longer affect the current window.

Perhaps this should be considered as a feature to add in the future.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

2

Trevor,

On of the short comings with gis.m that I now find is that it is
impossible to zoom to a file with the new interface since shell
commands no longer affect the current window.

Shell commands do affect the region, which affects the window if it is
redrawn. Currently there are two redraw buttons. The one on the left draws
changes in layers. The one on the redraws everything and will draw correctly
if the region has been changed.

I imagine that if I change the region and change a layer and use the left
redraw button I'll get two layers rendered at different regions which is a
bug. I just tried this and indeed it is so.

The correct thing for us to do is have one redraw button and a belief state
about the region. If the region is not in our belief state we should assert
that the layers are dirty and must be redrawn.

--Cedric

3

Trevor,

It's fixed in CVS. There's no need for the zoom to current region button
anymore; I removed it.

-- Cedric

> On of the short comings with gis.m that I now find is that it is
> impossible to zoom to a file with the new interface since shell
> commands no longer affect the current window.

Shell commands do affect the region, which affects the window if it is
redrawn. Currently there are two redraw buttons. The one on the left draws
changes in layers. The one on the redraws everything and will draw
correctly if the region has been changed.

I imagine that if I change the region and change a layer and use the left
redraw button I'll get two layers rendered at different regions which is a
bug. I just tried this and indeed it is so.

The correct thing for us to do is have one redraw button and a belief state
about the region. If the region is not in our belief state we should assert
that the layers are dirty and must be redrawn.

--Cedric

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

4

Cedric,

Unless there is a lot more changed than is clear here, it is a mistake to
remove the zoom to current region button. The standard display button IS
acting incorrectly as you describe it below, but didn't behave that way
previous to recent changes in display architecture. The left button should
never respect the generic region (set by g.region from the shell) but only
respect the region specific to that particular display.

Let me explain. Each display monitor needs to have an independent region
setting. That is, you should be able to zoom to one resolution and extents
in one display and a different resolution and extents in another. This is
the reason for the zoom to current region button. A particular display
should adopt the current region setting (i.e., generically set with
g.region) only if you explicitly tell it to do so. Otherwise, its region
settings should be completely independent of any other display. That is why
each display has its own saved region (mon1, mon2, etc). This makes it
possible to show a region in one display and the close up of a city in
another. In the same way, each display has its own independent layer tree
and can show a different set of maps from any other display.

I fear that you have changed it so that all displays now have the same
region settings. If so, it needs to be changed back.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Cedric Shock <cedricgrass@shockfamily.net>
Date: Wed, 3 May 2006 11:46:25 -0700
To: <grass5@grass.itc.it>
Cc: Trevor Wiens <twiens@interbaun.com>, Michael Barton
<michael.barton@asu.edu>
Subject: Re: [GRASS5] gis.m limitation

Trevor,

It's fixed in CVS. There's no need for the zoom to current region button
anymore; I removed it.

-- Cedric

On of the short comings with gis.m that I now find is that it is
impossible to zoom to a file with the new interface since shell
commands no longer affect the current window.

Shell commands do affect the region, which affects the window if it is
redrawn. Currently there are two redraw buttons. The one on the left draws
changes in layers. The one on the redraws everything and will draw
correctly if the region has been changed.

I imagine that if I change the region and change a layer and use the left
redraw button I'll get two layers rendered at different regions which is a
bug. I just tried this and indeed it is so.

The correct thing for us to do is have one redraw button and a belief state
about the region. If the region is not in our belief state we should assert
that the layers are dirty and must be redrawn.

--Cedric

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

5

On Wed, 3 May 2006 11:46:25 -0700
Cedric Shock <cedricgrass@shockfamily.net> wrote:

Trevor,

It's fixed in CVS. There's no need for the zoom to current region button
anymore; I removed it.

Cedric,

I'm not sure your fix is right.

Although it does allow for shell commands to affect views directly,
what it does unfortunately create is an odd situation where if you have
two windows open, looking at two different zooms, their independence is
lost. This is not good as one of the things that Michael spent time
working on was creating a situation where the could be independent.

I think a better solution would have been to have both buttons present
and possibly two more to zoom to a file.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

6

Michael, Trevor,

Oops! You both caught me on this one. I substituted one bug for another. I'll
change it back and find a similar solution to the assumption of a clean
refresh.

By the way, multiple displays have never worked for me in gis.m. I can open a
new one, but once I do I can never do anything with the old one other than
pan, zoom, etc. Is there something I'm missing?

--Cedric

7

Cedric Shock wrote:

> On of the short comings with gis.m that I now find is that it is
> impossible to zoom to a file with the new interface since shell
> commands no longer affect the current window.

Shell commands do affect the region, which affects the window if it is
redrawn. Currently there are two redraw buttons. The one on the left draws
changes in layers. The one on the redraws everything and will draw correctly
if the region has been changed.

I imagine that if I change the region and change a layer and use the left
redraw button I'll get two layers rendered at different regions which is a
bug. I just tried this and indeed it is so.

The correct thing for us to do is have one redraw button and a belief state
about the region. If the region is not in our belief state we should assert
that the layers are dirty and must be redrawn.

For redrawing using the region from the WIND file, that should
probably be replaced by an option to update gis.m's current region
from the WIND file. That would automatically invalidate all rendered
layers, so the next time the display is updated, everything would be
re-rendered.

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

8

Hmmm. They work for me quite well. When you open a new display you need to
add maps to it.

To switch back to the old display, you need to click it. But due to binding
limitations in TclTk (maybe you know a way around these?) you can't just
click in the title bar or status bar; you have to click any place BUT these
places. Switching back to the first display should show its independent
layer tree and zoom.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Cedric Shock <cedricgrass@shockfamily.net>
Date: Wed, 3 May 2006 13:21:27 -0700
To: <grass5@grass.itc.it>
Cc: Michael Barton <michael.barton@asu.edu>, Trevor Wiens
<twiens@interbaun.com>
Subject: Re: [GRASS5] gis.m limitation

Michael, Trevor,

Oops! You both caught me on this one. I substituted one bug for another. I'll
change it back and find a similar solution to the assumption of a clean
refresh.

By the way, multiple displays have never worked for me in gis.m. I can open a
new one, but once I do I can never do anything with the old one other than
pan, zoom, etc. Is there something I'm missing?

--Cedric

9

I think a better solution would have been to have both buttons present
and possibly two more to zoom to a file.

Hi. Some ideas,

Perhaps all we need better labels.

A clear "monitor 1" title bar at the top of the command list in the
"GIS Manager" window would make it clear which window you are currently
working with. Actually this seems like a perfect place to use tabs.

Clearer labeling could help the confused zoom to region buttons too,
we have:

Zoom to current region and redraw all layers
Return to previous zoom
Zoom to saved region
Zoom to default region

"Zoom to current region" => "Return to original zoom settings"
(return/revert ?)
"Zoom to current region" is unclear about which "current" we are talking
about*. Try not to use ambiguous words if possible.

[*] Similar on the GUI startup screen: "Path to location" could be read
as "Road to destination". As that page isn't translated**, I can imagine
someone new to the program/jargon trying to figure out what it means
using a dictionary and becoming rather confused...

[**] what are the translation possibilities for TclTk menus and shell
scripts?

but back to gis.m,

I'm not sure what happened to a "set GIS region from current zoom"
button, or if that is wanted?

The monitors should all start up with the GIS region settings, which
initially would be what's in the current WIND.
Only Config->Region->Manage Region should be able to modify that, both
for new monitors and the main mapset setting.

Please double check 'g.region nsres= ewres= -a' has been used where
needed so after zoom/pan in the Map window the region settings are
not left in a fractional state; and that the Map display zoom has not
affected the mapset's WIND file.

Michael: your tooltips are tiny? Mine come out double size. ?!
Arrow, Zoom in/out, pan, query, ruler, and Save don't have tooltips
on the Map Display windows.

Hamish

10

Thanks for the ideas Hamish. See below.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Hamish <hamish_nospam@yahoo.com>
Date: Thu, 4 May 2006 17:15:46 +1200
To: Trevor Wiens <twiens@interbaun.com>
Cc: <cedricgrass@shockfamily.net>, <grass5@grass.itc.it>,
<michael.barton@asu.edu>
Subject: Re: [GRASS5] gis.m limitation

I think a better solution would have been to have both buttons present
and possibly two more to zoom to a file.

Hi. Some ideas,

Perhaps all we need better labels.

Agreed

A clear "monitor 1" title bar at the top of the command list in the
"GIS Manager" window would make it clear which window you are currently
working with. Actually this seems like a perfect place to use tabs.

This might be a help. But see the effects of the Cedric's new changes to the
GIS Manager and see if this helps. The layer tree now changes depending on
which display window your mouse is hovering over.

I tried tabs and 1) it is much more difficult than simply switching the
layer tree like now; 2) the user would have to pick the right tab but the
correct layer tree is automatically displayed currently.

Clearer labeling could help the confused zoom to region buttons too,
we have:

Zoom to current region and redraw all layers
Return to previous zoom
Zoom to saved region
Zoom to default region

"Zoom to current region" => "Return to original zoom settings"
(return/revert ?)
"Zoom to current region" is unclear about which "current" we are talking
about*. Try not to use ambiguous words if possible.

I agree that this can seem ambiguous. Return to original zoom settings is
not right either. I'm assuming that you've been displaying maps. Then you to
go g.region and change the region. Really, you are zooming to the
system-wide region setting, but that is a lot of verbage for mouse-over
help. I haven't seen anything any better than wyat we already have. Perhaps
you or someone else can think of a better, non-technical term.

[*] Similar on the GUI startup screen: "Path to location" could be read
as "Road to destination". As that page isn't translated**, I can imagine
someone new to the program/jargon trying to figure out what it means
using a dictionary and becoming rather confused...

But it's better than 'select GRASS database'. If I had my druthers, we'd
call locations "projection folders". But the term "location" permeates many
things GRASS. I've tried to improve this a bit by calling it "projection
location". But I really wanted something easier. Just couldn't think of
something better in the time I've had. Suggestions?

[**] what are the translation possibilities for TclTk menus and shell
scripts?

I guess I don't know.

but back to gis.m,

I'm not sure what happened to a "set GIS region from current zoom"
button, or if that is wanted?

What did this do?

The monitors should all start up with the GIS region settings, which
initially would be what's in the current WIND.
Only Config->Region->Manage Region should be able to modify that, both
for new monitors and the main mapset setting.

This is the way it is now. I simply saved monitor settings to a saved region
file. Cedric's new method saves it to a TclTk variable.

Please double check 'g.region nsres= ewres= -a' has been used where
needed so after zoom/pan in the Map window the region settings are
not left in a fractional state; and that the Map display zoom has not
affected the mapset's WIND file.

I can look at the -a option. The map display does not change WIND.

Michael: your tooltips are tiny? Mine come out double size. ?!
Arrow, Zoom in/out, pan, query, ruler, and Save don't have tooltips
on the Map Display windows.

We are now trying to set these in the options database.So I'm not sure why
the size difference.

The lack of tooltips for several buttons is because they are radio buttons
and radio buttons don't allow for tooltips.

Hamish

11

> A clear "monitor 1" title bar at the top of the command list in the
> "GIS Manager" window would make it clear which window you are
> currently working with. Actually this seems like a perfect place to
> use tabs.

This might be a help. But see the effects of the Cedric's new changes
to the GIS Manager and see if this helps. The layer tree now changes
depending on which display window your mouse is hovering over.

Maybe even more confusing, on X windows it is common for the window
under the mouse to have the focus automatically (no clicking).

I think the
|
-- Raster 1
|
-- Raster 2

tree definently needs to terminate itself in a "Display Monitor 1" bar.

I tried tabs and 1) it is much more difficult than simply switching
the layer tree like now;

Limitations? hah! you guys are too good.

2) the user would have to pick the right tab but the correct layer
tree is automatically displayed currently.

when a display monitor grabs the focus that tab could be pushed to the
fore as well, and vise versa.

[better wording of the opening GUI]

No suggestions yet, other than it should be exact in meaning and if not
a common word it should at least imply what it does.

Hamish

12

From: Hamish <hamish_nospam@yahoo.com>
Date: Thu, 4 May 2006 21:47:21 +1200
To: Michael Barton <michael.barton@asu.edu>
Cc: <twiens@interbaun.com>, <cedricgrass@shockfamily.net>,
<grass5@grass.itc.it>
Subject: Re: [GRASS5] gis.m limitation

Maybe even more confusing, on X windows it is common for the window
under the mouse to have the focus automatically (no clicking).

This is what Cedric implemented. I can't for the life of me remember why I
decided against it (I did explore this), since it is considerably more
sensible.

I think the
|
-- Raster 1
|
-- Raster 2

tree definently needs to terminate itself in a "Display Monitor 1" bar.

This can be added with minimal hassle. BUT it takes up 1+ line of fairly
limited real estate in the layer tree. Is it REALLY needed given that it is
pretty obvious now that the layer tree switches automatically and very
smoothly as you move the mouse focus from one display to the next?

I tried tabs and 1) it is much more difficult than simply switching
the layer tree like now;

Limitations? hah! you guys are too good.

You're too kind. I did try this out and the automatic switching was much
more complicated. Then I got to thinking about the labeling and what if
someone had the audacity to open 10 displays.

I understand what you're getting at, but I think that simpler is better.
Maybe we could make better use of the empty area to the right of the layer
tree for signaling if this is needed.

Also, looking ahead, we've had some discussions about switching much of the
current menu structure to a toolbox metaphor. Trevor Wiens has suggested
tabs to let a user switch from a layer tree tool box to other tool boxes
(e.g., vector network or raster hydrology). This would keep a compact user
control window, while giving an alternative to menus that provides better
access to the several hundred GIS tools in GRASS.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton