[GRASS-dev] gis.m improvements

Michael, Cedric and everyone involved in improving the GUI

I just tried out your latest changes and they are great.

Here are some things that should be really easy to do and improve
the interface experience further:

1. The intro screen uses to much bold font formatting.

2. Likewise, bubble hints should be formatted with normal font weight.

3. NVIZ respects my system settings for menu colors. I think so should
the GUI module forms and gis.m. It just integrates much better
with the rest of the user desktop.

4. querying raster maps from a Map Display is buggy: if my working
region is set smaller than the raster's total extent and I
user "Zoom to selected map", querying will return NULL values "*",
for all parts of the displayed map outside the working region.

5. I think there are too many "add some layer" buttons in gis.m's
icon bar. I alwas need a few seconds to find the one I need.
I would suggest reducing this to the principle icons for
rasters, vectors, labels and misc and adding a little dropdown box
next to each which will reveal additional addable layer types.

6. There should be a menu entry "Layers" in the menu bar, right
next to "File" in which the user can find all functions that
are currently only reachable via icons:

Layers
  Raster
    Add raster layer
    Add RGB or HIS
    ...
  Vector
    Add vector
    Add thematic
    ...
  Labels
  Misc
  ...
  --------
  Edit layer (digitize)
  Show layer info (r.info, v.info, ...)
  Zoom to current layer
  NVIZ
  ...

7. The Config menu should really be removed and all its
items added to File -> Settings.
HOWEVER, prior to this, the old "Settings" item should
be removed to "Workspace". And moved to the top of
the "File" menu.

8. The Workspace icons I think need to move to the top left
position in the icon bar, to reflect the order of the
drop-down menu.

9. The file menu needs to get a "New Map Display" item, preferably
below the "Workspace" menu item (see above).

10. I really think that some layer options (especially
for vectors) should be grouped using tabs, like:

Symbology|Labels|Queries|Misc

Benjamin

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeo-Information Science)
Institut für Ur- und Frühgeschichte
(Institute of Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

My 0,01 PLN as to recent (CVS 2006.05.07) gis.m:

1.
v.digit via "Digitize map" button errors (see my other post).

2.
Zoom-out in 1 click mode doesn't center the image as needed. 1click
zoom-in is ok.

3.
Zoom in/out step in 1 click mode should be increased.

4.
d.rast.num layers are never displayed in "Explore Draw Mode",
information window "Cell values can only be displayed for regions of <
10,000 cells" always pops up.

5.
zooming with d.rast.arrow or d.rast.num layer displayed leads to an
error:

child process exited abnormally
child process exited abnormally
    while executing
"exec -- g.pnmcomp in=31576.3.ppm mask=31576.3.pgm opacity=1.0
background=255:255:255 width=642 height=482 out=31576.1.ppm

& /dev/null" ("eval" body line 1) invoked from within

"eval exec -- $cmd $args >& /dev/null"
    (procedure "run" line 6)
    invoked from within
"run g.pnmcomp in=31576.3.ppm mask=31576.3.pgm opacity=1.0
background=255:255:255 width=642 height=482 out=31576.1.ppm" ("eval"
body line 1) invoked from within
"eval run $cmd $args"
    (procedure "runcmd" line 6)
    invoked from within
"runcmd "g.pnmcomp in=$complist($mon) mask=$masklist($mon) opacity=
$opclist($mon) background=255:255:255 width=$driver_w($mon) height=
$driver_h($mon) o..." (procedure "MapCanvas::composite" line 18)
invoked from within "MapCanvas::composite $mon"
    (procedure "MapCanvas::drawmap" line 45)
    invoked from within
"MapCanvas::drawmap $mon"
    (procedure "MapCanvas::display_server" line 9)
    invoked from within
"MapCanvas::display_server"
    ("after" script)

The above error or similar happen in many cases when displaying
d.rast.arrow or d.rast.num layers is involved, only I can't extract
situations specific enough to be able to report them - they "just
happen". So please just add such layers to your stack in gis.m and try
turning them off/on then redisplay, change region settings, draw
mode, play with panning etc. - errors will gladly pop up.

Moreover, handling these errors is bad I think: any such error make the
all "Map displays" not responsive - gis.m has to restarted, thus
setting the layers etc. has to be re-done. Could these errors be made
less fatal?

6.
Mouse scroll doesn't work in main gis.m window. Also, it is faulty in
the "GIS.m - Output" window. Sometimes it works and scrolls a few
lines, then stucks.

7.
Could all instances of "GIS.m" string be replaced with "gis.m"
- to reflect the program name? (Either "GIS Manager" or "gis.m", not
the mixture of both).

8.
Draw mode icons are corrupted.

9.
"Explore Draw Mode" is excellent! Make it default? gis.m and current
region settings are independent anyway, and "Explore Draw Mode" seems
natural, intuitive. Newcomers will like it IMHO.

I really start liking gis.m look and feel. More important, it has
become substantialy faster recently. Though still slower than X11...
Anyway, Good job!

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

Thanks for the information Maciek.

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: Maciek Sieczka <werchowyna@epf.pl>
Date: Sun, 7 May 2006 15:09:47 +0200
To: Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>
Cc: <grass-dev@grass.itc.it>, <cedricgrass@shockfamily.net>,
<michael.barton@asu.edu>
Subject: Re: [GRASS-dev] gis.m improvements

My 0,01 PLN as to recent (CVS 2006.05.07) gis.m:

1.
v.digit via "Digitize map" button errors (see my other post).

2.
Zoom-out in 1 click mode doesn't center the image as needed. 1click
zoom-in is ok.

3.
Zoom in/out step in 1 click mode should be increased.

4.
d.rast.num layers are never displayed in "Explore Draw Mode",
information window "Cell values can only be displayed for regions of <
10,000 cells" always pops up.

5.
zooming with d.rast.arrow or d.rast.num layer displayed leads to an
error:

child process exited abnormally
child process exited abnormally
    while executing
"exec -- g.pnmcomp in=31576.3.ppm mask=31576.3.pgm opacity=1.0
background=255:255:255 width=642 height=482 out=31576.1.ppm

& /dev/null" ("eval" body line 1) invoked from within

"eval exec -- $cmd $args >& /dev/null"
    (procedure "run" line 6)
    invoked from within
"run g.pnmcomp in=31576.3.ppm mask=31576.3.pgm opacity=1.0
background=255:255:255 width=642 height=482 out=31576.1.ppm" ("eval"
body line 1) invoked from within
"eval run $cmd $args"
    (procedure "runcmd" line 6)
    invoked from within
"runcmd "g.pnmcomp in=$complist($mon) mask=$masklist($mon) opacity=
$opclist($mon) background=255:255:255 width=$driver_w($mon) height=
$driver_h($mon) o..." (procedure "MapCanvas::composite" line 18)
invoked from within "MapCanvas::composite $mon"
    (procedure "MapCanvas::drawmap" line 45)
    invoked from within
"MapCanvas::drawmap $mon"
    (procedure "MapCanvas::display_server" line 9)
    invoked from within
"MapCanvas::display_server"
    ("after" script)

The above error or similar happen in many cases when displaying
d.rast.arrow or d.rast.num layers is involved, only I can't extract
situations specific enough to be able to report them - they "just
happen". So please just add such layers to your stack in gis.m and try
turning them off/on then redisplay, change region settings, draw
mode, play with panning etc. - errors will gladly pop up.

Moreover, handling these errors is bad I think: any such error make the
all "Map displays" not responsive - gis.m has to restarted, thus
setting the layers etc. has to be re-done. Could these errors be made
less fatal?

6.
Mouse scroll doesn't work in main gis.m window. Also, it is faulty in
the "GIS.m - Output" window. Sometimes it works and scrolls a few
lines, then stucks.

7.
Could all instances of "GIS.m" string be replaced with "gis.m"
- to reflect the program name? (Either "GIS Manager" or "gis.m", not
the mixture of both).

8.
Draw mode icons are corrupted.

9.
"Explore Draw Mode" is excellent! Make it default? gis.m and current
region settings are independent anyway, and "Explore Draw Mode" seems
natural, intuitive. Newcomers will like it IMHO.

I really start liking gis.m look and feel. More important, it has
become substantialy faster recently. Though still slower than X11...
Anyway, Good job!

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko
najlepsze z nich!
http://katalog.panoramainternetu.pl/

6. There should be a menu entry "Layers" in the menu bar, right
next to "File" in which the user can find all functions that
are currently only reachable via icons:

Layers

I will second the earier comments that having both "layers" used for GUI
map layers and the existing vector/table layers is highly confusing and
should be avoided if possible. Please find another word...?

Hamish

On Mon, 8 May 2006 12:32:34 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

> 6. There should be a menu entry "Layers" in the menu bar, right
> next to "File" in which the user can find all functions that
> are currently only reachable via icons:
>
> Layers

I will second the earier comments that having both "layers" used for GUI
map layers and the existing vector/table layers is highly confusing and
should be avoided if possible. Please find another word...?

The normal term for the different raster and vector components to a
map is layers. It is the standard abstraction used in GIS software
and drawing programs. The use of the term layers for vector file links
to attribute tables should not be layers as I've pointed out before and
will continue to do so. It seems impossible to remove this confusing
naming because it is an OGC standard so the fact that it is wrong
doesn't seem to matter. Thus as I see it there are two options.

One, continue to use layer in the GUI in the normal fashion and
modify the use of layers in reference to vector attribute linkages
using a term like "virtual layers", which will contain enough reference
to the OGC terminology to provide a link but still distinguishes from
the normal use of the term. Note, I would normally run away screaming
from the suggestion to use the word virtual in naming anything, but in
this context, it just might work.

Two, change to a different term in the GUI rather than layers and
further add to the confusion of terminology in GRASS, making it even
more inaccessible to naive users. Since one of the main goals of this
GUI revamp was to increase accessibility, I think this is not an option.

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)

Tevor articulated this very well. This continues a discussion that went on a
month or so back.

The "layers" for vectors are actually "key fields" for joining attribute
tables to vector objects. Each key field (currently called a "layer") can
join one attribute table to the objects in a vector file.

I'd vote for changing the name to "key field", "key", or something along
that line that more clearly denotes how this handy feature actually
functions, and referencing any relationship to OGC layers in the docs (a
rather indirect relationship it seems to me, because this is not really the
same as the data layers in something like a DXF file).

In most GIS texts I've used, layers refers to geospatial data that can be
overLAYED (composited together) to make up a composite map. Using another
term would be very confusing to GIS users.

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: Trevor Wiens <twiens@interbaun.com>
Date: Sun, 7 May 2006 21:16:38 -0600
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] gis.m improvements

On Mon, 8 May 2006 12:32:34 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

6. There should be a menu entry "Layers" in the menu bar, right
next to "File" in which the user can find all functions that
are currently only reachable via icons:

Layers

I will second the earier comments that having both "layers" used for GUI
map layers and the existing vector/table layers is highly confusing and
should be avoided if possible. Please find another word...?

The normal term for the different raster and vector components to a
map is layers. It is the standard abstraction used in GIS software
and drawing programs. The use of the term layers for vector file links
to attribute tables should not be layers as I've pointed out before and
will continue to do so. It seems impossible to remove this confusing
naming because it is an OGC standard so the fact that it is wrong
doesn't seem to matter. Thus as I see it there are two options.

One, continue to use layer in the GUI in the normal fashion and
modify the use of layers in reference to vector attribute linkages
using a term like "virtual layers", which will contain enough reference
to the OGC terminology to provide a link but still distinguishes from
the normal use of the term. Note, I would normally run away screaming
from the suggestion to use the word virtual in naming anything, but in
this context, it just might work.

Two, change to a different term in the GUI rather than layers and
further add to the confusion of terminology in GRASS, making it even
more inaccessible to naive users. Since one of the main goals of this
GUI revamp was to increase accessibility, I think this is not an option.

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)

Benjamin,

Thanks for the input. 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: Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>
Date: Sun, 07 May 2006 12:17:06 +0200
To: GRASS devel <grass-dev@grass.itc.it>
Subject: [GRASS-dev] gis.m improvements

Michael, Cedric and everyone involved in improving the GUI

I just tried out your latest changes and they are great.

Here are some things that should be really easy to do and improve
the interface experience further:

1. The intro screen uses to much bold font formatting.

The only bold is on the 4 welcome lines. The rest is standard font.

2. Likewise, bubble hints should be formatted with normal font weight.

I think this is already changed. My help is not bold.

3. NVIZ respects my system settings for menu colors. I think so should
the GUI module forms and gis.m. It just integrates much better
with the rest of the user desktop.

I'm not so sure about this, though I understand your point. I'm not sure how
easy it is to lift the menu colors on all platforms. We'd need to see how it
looks if you do this. It might not work right. Most of this is now set in
the options database. Perhaps the better thing would be have a little gui
app that would allow you to set it to whatever you want.

4. querying raster maps from a Map Display is buggy: if my working
region is set smaller than the raster's total extent and I
user "Zoom to selected map", querying will return NULL values "*",
for all parts of the displayed map outside the working region.

I've been looking at this and here is what happens. By design, gis.m does
not mess with the WIND file. You can only change WIND via g.region. By
design, the displays do not read the WIND file unless you explicitly
instruct a display to do so (zoom to current region). This is so that each
display can have an independent region setting (extengs, resolution). So far
so good.

But r.what reads the WIND file. If its coordinate input is outside the
extents listed in the file, it gives an error. V.what does NOT worry about
the WIND file and will query any coordinates you give it.

It seems that r.what needs to be modified so as to not worry about the
extents in the WIND file. I don't see an easy work around for this (beyond
setting the region with g.region). We really don't want to have the map
displays mess with the WIND file.

5. I think there are too many "add some layer" buttons in gis.m's
icon bar. I alwas need a few seconds to find the one I need.
I would suggest reducing this to the principle icons for
rasters, vectors, labels and misc and adding a little dropdown box
next to each which will reveal additional addable layer types.

Maybe. But what you might think is best hidden out of the way in a drop
down, someone else might think is essential to have on top (e.g., thematic
maps). Unless we are out of space, it seems best to have as many of the
layer tools as accessible as possible.

6. There should be a menu entry "Layers" in the menu bar, right
next to "File" in which the user can find all functions that
are currently only reachable via icons:

Why should we add another menu to duplicate what is already accessible in
the tool bars?

7. The Config menu should really be removed and all its
items added to File -> Settings.
HOWEVER, prior to this, the old "Settings" item should
be removed to "Workspace". And moved to the top of
the "File" menu.

Combining the file and config menus would make for a very long and complex
menu. Do we really want this? The menus are already nested too deeply for
easy use.

What to call "settings". I liked workspace. They were originally called
"groups" and several people objected to the change from group to workspace.
In discussing this with Markus, they got changed to settings. Workspace is
fine with me. Settings is fine with me. I just noticed that someone has now
changed this to "layers". Groups mixes groups of layers in the layer tree
and saved files of information about layers and their options. So I don't
like the groups. I'm not sure that "layers" is quite what is happening here,
although we are saving a file with information about what information goes
in which layers. Let's standardize and stick with it. What does everyone
else like?

Workspace: 1

Settings:

Layers:

Groups:

Other (offer name and justification):

8. The Workspace icons I think need to move to the top left
position in the icon bar, to reflect the order of the
drop-down menu.

I'm for taking the workspace/settings/layers/groups icons out of the tool
bar and just leaving them in the menu. They have accelerator (shortcut)
keys. The tool bar seems like needless duplications (see #6).

Anyone have objections to this?

9. The file menu needs to get a "New Map Display" item, preferably
below the "Workspace" menu item (see above).

See #6

10. I really think that some layer options (especially
for vectors) should be grouped using tabs, like:

Symbology|Labels|Queries|Misc

Probably a good idea, though this is most relevant to vectors, thematic
layers, and may vector chart layers. The others are so short that this is
not worth it. However, it would also take some serious rewriting of the
option panel code. I'm trying to get all this stabilized so we can have a
6.2 feature freeze.

Benjamin

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeo-Information Science)
Institut für Ur- und Frühgeschichte
(Institute of Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

Maciek,

Very recent changes may affect your other observations.

The one click changes by 30% (e.g., zoom in to 130%, zoom out to 70%). This
seems like a pretty good compromise. This could be changed of course, but
I'm sure it's too little for some people and likely too much for others.
What would you put it at?

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: Maciek Sieczka <werchowyna@epf.pl>
Date: Sun, 7 May 2006 15:09:47 +0200
To: Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>
Cc: <grass-dev@grass.itc.it>, <cedricgrass@shockfamily.net>,
<michael.barton@asu.edu>
Subject: Re: [GRASS-dev] gis.m improvements

3.
Zoom in/out step in 1 click mode should be increased.

Hmmm, do you really think so?
vector layer in gis.m map 1:1 to the GRASS database
and so do raster and 3d raster layers.
The word layer is a little bit fuzzy in the GIS
world, but I think people can live with it OK.
Anyway, I can't think of anything better to call it.

Hamish wrote:

6. There should be a menu entry "Layers" in the menu bar, right
next to "File" in which the user can find all functions that
are currently only reachable via icons:

Layers

I will second the earier comments that having both "layers" used for GUI
map layers and the existing vector/table layers is highly confusing and
should be avoided if possible. Please find another word...?

Hamish

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

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeo-Information Science)
Institut für Ur- und Frühgeschichte
(Institute of Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

Thanks for the reply, Michael, just some further thoughts:

But r.what reads the WIND file. If its coordinate input is outside the
extents listed in the file, it gives an error. V.what does NOT worry about
the WIND file and will query any coordinates you give it.

It seems that r.what needs to be modified so as to not worry about the
extents in the WIND file.

Well, that's very understandable given how raster maps are handled
through the C API.

I don't see an easy work around for this (beyond
setting the region with g.region). We really don't want to have the map
displays mess with the WIND file.

I also don't see an easy way. But is it really a good idea to have
gis.m use its own concept of a region? Does someone who uses
gis.m as default GUI not expect the map display and g.region to
work in sync?

Why should we add another menu to duplicate what is already accessible in
the tool bars?

Because it is common standard for GUIs that all program functionality
should be accessible via the menu bar and icons only provide shortcuts.
For several reasons (mostly from the point of view of a novice user):
1. there are some people (like myself) who don't remember icon functions
very well and don't want to wait for tooltips to appear
2. Keyboard shortcuts can be displayed in the menu
3. If you are looking for a certain functionality in a program you are
not acquainted with, its much easier to find that in a well-organized
menubar
4. This opens the possibility for users to hide iconbars and make other
use of those pixels, e.g. for bigger map display.

in which layers. Let's standardize and stick with it. What does everyone
else like?

Workspace: 1

Workspace: 2 (that's what the icons say)

I'm for taking the workspace/settings/layers/groups icons out of the tool
bar and just leaving them in the menu. They have accelerator (shortcut)
keys. The tool bar seems like needless duplications (see #6).

Anyone have objections to this?

I think this is OK.

10. I really think that some layer options (especially
for vectors) should be grouped using tabs, like:

Symbology|Labels|Queries|Misc

Probably a good idea, though this is most relevant to vectors, thematic
layers, and may vector chart layers. The others are so short that this is
not worth it. However, it would also take some serious rewriting of the
option panel code. I'm trying to get all this stabilized so we can have a
6.2 feature freeze.

I understand that. Seems like something to be explored in the long run.

Benjamin

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeo-Information Science)
Institut für Ur- und Frühgeschichte
(Institute of Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeo-Information Science)
Institut für Ur- und Frühgeschichte
(Institute of Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

But r.what reads the WIND file. If its coordinate input is outside the
extents listed in the file, it gives an error. V.what does NOT worry
about the WIND file and will query any coordinates you give it.

It seems that r.what needs to be modified so as to not worry about the
extents in the WIND file. I don't see an easy work around for this
(beyond setting the region with g.region). We really don't want to
have the map displays mess with the WIND file.

The default behaviour of r.what can't change. All raster modules have to
respect MASK and regions the same way. (e.g. setting the region can be
used as a cheap de facto MASK in scripts) However a flag could be added
to r.what to test vs. the raster's window instead of the region's. I
expect doing this could be problematic.

What to call "settings"

..

Workspace: 1
Settings:
Layers:
Groups:
Other (offer name and justification):

"settings" is too generic. Can I change the display font there? the
default database? I think "workspace" makes good sense. layers and
groups, no.

call layers in the GUI "display layers"? "graphical layers"?

> 10. I really think that some layer options (especially
> for vectors) should be grouped using tabs, like:
>
> Symbology|Labels|Queries|Misc

Probably a good idea, though this is most relevant to vectors,
thematic layers, and may vector chart layers. The others are so short
that this is not worth it. However, it would also take some serious
rewriting of the option panel code. I'm trying to get all this
stabilized so we can have a 6.2 feature freeze.

This seems like a good point to look into the vector GUI controls. They
are way too complex and overwhelming for a new user. Your first day
flying a plane and you're given a 747 cockpit of options..
Could more obscure controls be put into background "advanced" tabs? or
"area/point/line" themed tabs? (with redundancy, but that's ok)

Hamish

> I will second the earier comments that having both "layers" used for
> GUI map layers and the existing vector/table layers is highly
> confusing and should be avoided if possible. Please find another
> word...?

Hmmm, do you really think so?

I do. There is enough GIS and GRASS jargon to learn that to start
having words with two meanings is going to be highly confusing and
frustrating for new folks trying to learn the system. And after
fuzzy translations the situation can get even worse.

vector layer in gis.m map 1:1 to the GRASS database
and so do raster and 3d raster layers.

eh? (note the double use of "database" too....)

The word layer is a little bit fuzzy in the GIS
world, but I think people can live with it OK.
Anyway, I can't think of anything better to call it.

either vector layers go back to being called fields or gui layers change
to "[qualifier] layers"? The second option is the least painful; it
is good to consider the long term too. Sorry, no great ideas/solution.

shrug,
Hamish

On Sun, 07 May 2006 23:03:45 -0700
Michael Barton <michael.barton@asu.edu> wrote:

Maciek,

Very recent changes may affect your other observations.

Please give them a try if you don't mind anyway.

The one click changes by 30% (e.g., zoom in to 130%, zoom out to
70%). This seems like a pretty good compromise. This could be changed
of course, but I'm sure it's too little for some people and likely
too much for others. What would you put it at?

I like the d.zoom default behaviour in this respect. It lets me quickly
change the perspective.

d.zoom help

<snip>

    zoom Magnification: >1.0 zooms in, <1.0 zooms out
           options: 0.001-1000.0
           default: 0.75

Does this mean 75%? It could, looking at the display:

1.png - g.region vect=, d.vect , d.zoom -> 1x midmouse
2.png - g.region vect=, gis.m, "Zoom to current region...", "Zoom Out"
        -> 1x leftmouse

Maciek

---------------------
Polkosta Po?udnie - specjalistyczna firma w bran?y ogrodze?, bram oraz wszelkiego rodzaju zabezpiecze?.
www.polkostapoludnie.pl

(attachments)

1.png
2.png

What about making it 50%?

Anybody else want to weigh in on this?

We simply need to pick a value that is most useful to most people.
Sometimes people who like it the way it is are those who are silent.

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: Maciek Sieczka <werchowyna@epf.pl>
Date: Mon, 8 May 2006 18:54:53 +0200
To: Michael Barton <michael.barton@asu.edu>
Cc: <benjamin.ducke@ufg.uni-kiel.de>, <grass-dev@grass.itc.it>,
<cedricgrass@shockfamily.net>
Subject: Re: [GRASS-dev] gis.m improvements

On Sun, 07 May 2006 23:03:45 -0700
Michael Barton <michael.barton@asu.edu> wrote:

Maciek,

Very recent changes may affect your other observations.

Please give them a try if you don't mind anyway.

The one click changes by 30% (e.g., zoom in to 130%, zoom out to
70%). This seems like a pretty good compromise. This could be changed
of course, but I'm sure it's too little for some people and likely
too much for others. What would you put it at?

I like the d.zoom default behaviour in this respect. It lets me quickly
change the perspective.

d.zoom help

<snip>

    zoom Magnification: >1.0 zooms in, <1.0 zooms out
           options: 0.001-1000.0
           default: 0.75

Does this mean 75%? It could, looking at the display:

1.png - g.region vect=, d.vect , d.zoom -> 1x midmouse
2.png - g.region vect=, gis.m, "Zoom to current region...", "Zoom Out"
        -> 1x leftmouse

Maciek

---------------------
Polkosta Po?udnie - specjalistyczna firma w bran?y ogrodze?, bram oraz
wszelkiego rodzaju zabezpiecze?.
www.polkostapoludnie.pl

Benjamin,

I'll try to answer this again. Hopefully, by sending it to the dev list
again more people will begin to understand the concepts behind independent
displays in the GIS Manager.

-------------------------------
Old GRASS UI:
One region setting, managed by g.region (and d.zoom), with information
stored in WIND. This information (extents, resolution) applies to ALL
display functions in ALL xmons for entire GRASS session.

Any x11 display that is open sees the same region (extents, resolution).

If you want to have 2 displays with different maps, you must 1) set the
region; 2) display the map; 3) change the region, layers, etc; 4) switch to
another x11 display; 5) display the new settings; and 6) DON'T TOUCH THE
FIRST DISPLAY (if you do, it will look just like the second one).

There is no way to maintain different maps in different displays.

-------------------------------
New GRASS UI:
Each display has its own region and layer settings.

If you want to display different maps in different windows (much more likely
than wanting to display 2 completely identical maps), simply set the region
(zoom) and layers for each display.

You can update each display (change line colors, layers to display, extents)
independently of any other display.

To do this, any given display cannot use the session-wide WIND settings. If
it did, ALL displays would have the same region settings. That is, multiple
displays cannot have different views if all of them use the identical extent
and resolution information in the single WIND file. Each display must
maintain its own region and layer settings.

Therefore, each display must ignore the WIND values--UNLESS the user wants a
particular display to adopt the extents and resolution in the single,
session-wide WIND file. In this case, there is a toolbar function that lets
you do this.
-------------------------------

If people like the flexibility of being able to have different maps (using
different layers, extents, and resolutions) represented in different
displays, then the interaction between displays and the WIND file cannot
work the way it used to when we did not have that flexibility.

Those of us working on the UI development, can achieve this flexibility in
the GUI and display architecture--by ignoring the WIND file. An alternative
way to do this is to change how g.region and the WIND file work. This is
probably preferable in the long run. But it requires considerably more
modification of GRASS architecture.

Cheers,
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: Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>
Date: Mon, 08 May 2006 09:15:47 +0200
To: GRASS devel <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] gis.m improvements

I also don't see an easy way. But is it really a good idea to have
gis.m use its own concept of a region? Does someone who uses
gis.m as default GUI not expect the map display and g.region to
work in sync?

Michael Barton wrote:

What about making it 50%?

Anybody else want to weigh in on this?

We simply need to pick a value that is most useful to most people.
Sometimes people who like it the way it is are those who are silent.

I normally use sqrt(2). 2:1 or 1:2 are probably too much for a single
step; sqrt(2) gives you 2:1 or 1:2 in two steps.

Whichever is chosen, the ratio should be symmetric, so that zoom-out
and zoom-in are inverses. IOW, if the default zoom-out is 1.3:1, the
zoom in should be 1:1.3 (0.77:1), not 0.7:1.

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

Michael Barton wrote:

> 3. NVIZ respects my system settings for menu colors. I think so should
> the GUI module forms and gis.m. It just integrates much better
> with the rest of the user desktop.

I'm not so sure about this, though I understand your point. I'm not sure how
easy it is to lift the menu colors on all platforms. We'd need to see how it
looks if you do this. It might not work right. Most of this is now set in
the options database. Perhaps the better thing would be have a little gui
app that would allow you to set it to whatever you want.

By default, the GUI shouldn't specify colours for most widgets. Tk
should be able to figure out the system defaults by itself.

> 4. querying raster maps from a Map Display is buggy: if my working
> region is set smaller than the raster's total extent and I
> user "Zoom to selected map", querying will return NULL values "*",
> for all parts of the displayed map outside the working region.

I've been looking at this and here is what happens. By design, gis.m does
not mess with the WIND file. You can only change WIND via g.region. By
design, the displays do not read the WIND file unless you explicitly
instruct a display to do so (zoom to current region). This is so that each
display can have an independent region setting (extengs, resolution). So far
so good.

But r.what reads the WIND file.

Everything which accesses raster maps will crop and resample them
according to the current region, which is whatever is in the WIND file
unless you set WIND_OVERRIDE to specify a saved region.

If its coordinate input is outside the
extents listed in the file, it gives an error. V.what does NOT worry about
the WIND file and will query any coordinates you give it.

It seems that r.what needs to be modified so as to not worry about the
extents in the WIND file. I don't see an easy work around for this (beyond
setting the region with g.region). We really don't want to have the map
displays mess with the WIND file.

I added WIND_OVERRIDE to deal with this specific issue. There is no
need to make specific modifications to any modules.

gis.m should be setting WIND_OVERRIDE for any command which
corresponds to a specific display, not just r.what.

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