[GRASS-dev] [GRASS GIS] #1778: Typing in g.region without parameters does not open a g.region window
GRASS GIS
trac at osgeo.org
Mon Sep 2 11:29:44 PDT 2013
#1778: Typing in g.region without parameters does not open a g.region window
----------------------------------------+-----------------------------------
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: g.region, r.colors, r.mask | Platform: Linux
Cpu: x86-64 |
----------------------------------------+-----------------------------------
Comment(by cmbarton):
It is not critical but I'm not sure I'd call it an enhancement. Not really
a bug either, though it will appear to be one to many users. The important
conceptual issue is, should the default behavior of GRASS modules when
called without arguments be
1. to launch a GUI dialog?
2. to do something?
If we agree on the behavior conceptually, then we can work out ways to
achieve it. Personally, I think it should be #1. Some others think it
should be #2 (launching a GUI only if there is a particular required
argument that has not been set). Currently, GRASS 7 is set for #2.
My vote for #1 comes from thinking about usability for people who are
novice or infrequent users of the command line and the fact that GRASS 7
appears to behave like #1 for most modules. This leads to what appears to
be inconsistent behavior of modules launched from the command line (even
though it is in fact consistent from the #2 approach). There is no way for
a user to know in advance whether a module called without arguments will
a) launch a GUI (has a particular required argument that is not set),
b) do something (runs a process with some default setting with no required
argument), or
c) do nothing (requires SOME argument, no particular argument to run).
A flag (-ui) can be added to any module to ensure it launches a GUI, but
is only necessary for a few modules. AFAICT, this behavior is not
documented anywhere (run g.region help or look in the manual for GRASS). I
tend to think that 'secret' behavior of any interface element is not a
good idea from the user perspective--even if the secret is inadvertent and
logical from other perspectives.
I think the argument for #2 is primarily one of easier, more rapid use of
modules from the command line by experienced and frequent users. There may
be other arguments that have not been articulated yet.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1778#comment:20>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list