(deriving this from " Re: [GRASS-dev] could r.stream.* become part of
GRASS core?"
On Thu, Apr 4, 2013 at 10:47 AM, Hamish <hamish_b@yahoo.com> wrote:
...
Very much straying offtopic now, I'd also advocate a series of
wrapper scripts to run from GUI buttons for simple-mode d.vect.
(see also my d.* helper/wrapper scripts in g6 addons like d.varea,
d.stations, and d.mark) I feel the current d.vect GUI window
is a bit overwhelming, but that's no reason to break up the base
module, since wrapper scripts can handle the "simple views",
and the full d.vect module gui could be there for "advanced"
mode.
I fully agree. Just today I tried the current wxGUI d.vect dialog window
(usually I use cmd line) and found it hard to find things since they
are in different tabs while belonging together.
Markus
On Thu, Apr 4, 2013 at 6:08 PM, Markus Neteler <neteler@osgeo.org> wrote:
(deriving this from " Re: [GRASS-dev] could r.stream.* become part of
GRASS core?"
On Thu, Apr 4, 2013 at 10:47 AM, Hamish <hamish_b@yahoo.com> wrote:
...
Very much straying offtopic now, I'd also advocate a series of
wrapper scripts to run from GUI buttons for simple-mode d.vect.
(see also my d.* helper/wrapper scripts in g6 addons like d.varea,
d.stations, and d.mark) I feel the current d.vect GUI window
is a bit overwhelming, but that's no reason to break up the base
module, since wrapper scripts can handle the "simple views",
and the full d.vect module gui could be there for "advanced"
mode.
I fully agree. Just today I tried the current wxGUI d.vect dialog window
(usually I use cmd line) and found it hard to find things since they
are in different tabs while belonging together.
So is it possible to improve first the d.vect dialog?
And what should the custom gui look like? It should probably provide
all the options but better organized (e.g. symbology containing
symbols, colors, lines...) and some less important features should be
hidden (collapsible pane).
Should there be also a dedicated gui for d.rast? I don't like the
possible inconsistency here.
Anna
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 05/04/13 08:23, Anna Kratochvílová wrote:
And what should the custom gui look like? It should probably provide
all the options but better organized (e.g. symbology containing
symbols, colors, lines...) and some less important features should be
hidden (collapsible pane).
AFAIU Hamish' suggestion, the idea is not to create _one_ dedicated GUI for d.vect, but rather to create several simplified GUIs which cater to specific usages of d.vect. To take his example of d.varea, you could have a GUI for displaying vector areas where the only options visible are those pertinent for displaying areas (so no symbols for example), where type=area is pre-chosen (and invisible), etc. A bit in the line of the QGIS GRASS toolbox, but only for d.vect.
Should there be also a dedicated gui for d.rast? I don't like the
possible inconsistency here.
d.rast is not nearly as feature-filled as d.vect, so I don't really see the need.
In any case the full d.vect module GUI has to stay available as well.
Moritz