[GRASS-dev] gis.m improvements

[Michael Barton]

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 at ufg.uni-kiel.de>
> Date: Sun, 07 May 2006 12:17:06 +0200
> To: GRASS devel <grass-dev at 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
> 
>