All,
I'm taking a look at the Python GUI, and wanted to make this comment.
Unlike the tcltk GUI, which leaves an open command line after it starts,
the Python GUI does not. This is an issue if you want to run a module
that the GUI hasn't noticed (in my case, r.in.onearth) - because you
can't bypass the GUI with the command line.
Is this fixable?
Richard Chirgwin
On 30/09/08 00:33, Richard Chirgwin wrote:
All,
I'm taking a look at the Python GUI, and wanted to make this comment.
Unlike the tcltk GUI, which leaves an open command line after it starts,
the Python GUI does not. This is an issue if you want to run a module
that the GUI hasn't noticed (in my case, r.in.onearth) - because you
can't bypass the GUI with the command line.Is this fixable?
Run the python gui with '&' appended at the end (e.g. 'g.gui wxpython &'). This runs the GUI in the background and releases the command prompt.
Moritz
On Tue, Sep 30, 2008 at 10:07 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 30/09/08 00:33, Richard Chirgwin wrote:
All,
I'm taking a look at the Python GUI, and wanted to make this comment.
Unlike the tcltk GUI, which leaves an open command line after it starts,
the Python GUI does not. This is an issue if you want to run a module
that the GUI hasn't noticed (in my case, r.in.onearth) - because you
can't bypass the GUI with the command line.Is this fixable?
Run the python gui with '&' appended at the end (e.g. 'g.gui wxpython &').
This runs the GUI in the background and releases the command prompt.
(Un)related: could be have
g.gui wx
as a shortcut? "wxpython" is really hard to type...
Markus
Markus:
(Un)related: could be have
g.gui wx
as a shortcut? "wxpython" is really hard to type...
The opt->options part of the parser only allows through full names.
My feeling is that adding shortcuts like that to the option list are
a really ugly solution, e.g. units="mi","miles","m","meters",... as exist
in some modules.
from-first few letters completion like is done for the option names is an
idea.
fortunately for g.gui it remembers your preferred gui type so unless
you are switching back and forth you just need to type "g.gui" most of
the time. (GRASS_GUI variable and the g.gui -u flag)
or add to .grass.bashrc something like "alias wxgui='g.gui wxpython'
Hamish
On 01/10/08 02:55, Hamish wrote:
Markus:
(Un)related: could be have
g.gui wx
as a shortcut? "wxpython" is really hard to type...The opt->options part of the parser only allows through full names.
But it should be possible to parse the answer taking into account shorter versions. See, for example, how type_opt is parsed on lines 478ff in display/d.vect/main.c.
Moritz
> The opt->options part of the parser only allows
through full names.
Moritz Lennert wrote:
But it should be possible to parse the answer taking into account
shorter versions. See, for example, how type_opt is parsed on lines
478ff in display/d.vect/main.c.
sure there's code in d.vect to handle it, but the parser won't actually
let you give anything but the full words listed in the ->options line.
G64> d.vect fields type=bound --q
ERROR: value <bound> out of range for parameter <type>
Legal range: point,line,boundary,centroid,area,face
Hamish
d.vect is not a good example, as it should be using
Vect_option_to_types(). No wonder that GRASS has so many LOC - lots of
duplication 
Maris.
2008/10/1, Moritz Lennert <mlennert@club.worldonline.be>:
On 01/10/08 02:55, Hamish wrote:
Markus:
(Un)related: could be have
g.gui wx
as a shortcut? "wxpython" is really hard to type...The opt->options part of the parser only allows through full names.
But it should be possible to parse the answer taking into account
shorter versions. See, for example, how type_opt is parsed on lines
478ff in display/d.vect/main.c.Moritz
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Hamish wrote:
> > The opt->options part of the parser only allows
> through full names.Moritz Lennert wrote:
> But it should be possible to parse the answer taking into account
> shorter versions. See, for example, how type_opt is parsed on lines
> 478ff in display/d.vect/main.c.sure there's code in d.vect to handle it, but the parser won't actually
let you give anything but the full words listed in the ->options line.
r33643 allows "enumerated" options (those with a list of valid
choices) to be abbreviated.
The answer must either be an exact match, or a prefix of exactly one
choice. E.g. for "g.list type=...", "rast" and "rast3d" are valid
(exact matches), "rast3" is valid (prefix of "rast3d" only), but "ras"
is rejected as ambiguous (prefix of both "rast" and "rast3d").
If an abbreviated answer is chosen, opt->answer (or for multiple
answers, opt->answers[i]) is replaced with a (deep) copy of the
unabbreviated name.
Note that where opt->multiple == YES, opt->answer *isn't*
reconstructed with the unabbreviated value, so this won't currently
work with g.parser (i.e. with scripts), or with anything that uses
opt->answer instead of opt->answers.
Needless to say, this shouldn't be backported until it has been
thoroughly tested.
--
Glynn Clements <glynn@gclements.plus.com>