[GRASS-dev] gis.m improvements

[Benjamin Ducke]

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