[GRASS-dev] d.rast.edit in wxgrass

[Paul Kelly]

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