On Wed, 13 Jun 2007, Michael Barton wrote:
GRASS command parsing from the wxgrass CLI:
Split the command into a list by spaces. I realize that this is a problem
for any command with spaces in the arguments, but I know of no better way to
do this in this context outside of making users type any command as a Python
list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead of
g.region rast=mymap res=30, I don't think anyone would want to use the CLI.
If the command has no arguments (i.e., len(cmdlist) == 0) AND it is NOT a
d.* command, send the original command string (not the list) to the
menuform.py processor (just like the menu would) to create the autogenerated
properties dialog. After this, the result of hitting "run" is the same as if
the properties dialog were called from the menu.
I don't get why it needs to do that specific processing - can you not just
run whatever is entered - if a command is run without arguments it will
pop up the GUI dialog anyway. Unless GRASS_UI_TERM is set. I suppose at
the minute it will always be a Tcl/Tk dialog that pops up, but I'm sure it
wouldn't be very hard to change G_parser() to check the GRASS_GUI variable
(or do something similar) and generate the correct autogenerated dialog
corresponding to the GUI that's in use.
If the command has no arguments AND IS a d.* command AND is in a hard coded
list of d.* commands for which we have defined layers in the layer tree,
create a layer tree item for that command (e.g., a raster layer for d.rast).
After that, the new layer is processed in the same way as one created by
pressing a layer button on the layer manager toolbar.
Sounds neat, consistent with non-display commands.
If the d.* command without arguments is NOT on the list for the layer tree,
generate get a message that it cannot be processed.
If the command HAS arguments and is NOT a d.* command, send the command list
(i.e., made by splitting on spaces -- not the original command string) to
cmd.Command for processing.
I think Glynn commented on this in a later mail but could you not just
take the whole string the user entered and pass it to the shell (or
cmd.exe on Windows) for executing - that way all the quoting rules etc.
that work in the shell will be consistent with how it works here and
reduce user confusion, and avoid you having to implement quoting handling
yourself in the space-splitting algorithm..
If the command HAS arguments and IS a d.* command, it is added to the list
of display layers managed within render.py for the map display that has the
focus and the UpdateMap method is called to update that display. There is a
That's a nice idea. I didn't realise it was so easily possible. Is it
possible to edit a display layer by editing the underlying raw d.*
command-line that it corresponds to, as an alternative to ticking boxes?
There obviously must be code to convert the GUI representation of the
layer to d.* command-line for drawing, and it sounds like you now have
new code to parse the d.* command-line and convert it to a GUI
representation (i.e. the display layer), so allowing editing of a layer by
changing the raw command-line it uses should be possible.
2nd splitting that allows for multiple d.* commands to be separated by
semi-colons. This may or may not be a good idea in the end, but I thought
I'd see how it worked out.
Shell uses semi-colons. But you could you not just enter the two commands
separately one after the other? I suppose if it was something that would
take a long time to draw then that would be slow.
All sounds good. I like the idea of the GUI having command-line features
and most of the command-line functionality being still available should
you need it. You could call it power-user features I suppose.
Paul
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
