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

[Glynn Clements]

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.

This is one case where shell=True *is* legitimate. At least with a
shell, the user can use quotes or backslashes to include spaces in
arguments. Or you could implement equivalent functionality yourself.

The latter is more work, but you can choose exactly which shell
functionality you want, e.g. allowing spaces (and other
metacharacters) without the other shell behaviour (sequences,
pipelines, redirection, variables, ....).

> 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.
> 
> 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.
> 
> 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.
> 
> 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
> 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.

This all looks suspiciously like DWIM, which is normally a bad thing
for non-trivial systems.

> >> If it was only from the menu, then it would be easy. I don't know if this is
> >> the case in menuform. I don't know exactly what is going on in this spot and
> >> haven't had time yet to figure it out.
> > 
> > The name "menuform.py" suggests that it has something to do with
> > menus. In which case, what is:
> > 
> >         if cmd[0][0:2] != "d.":
> > 
> > doing in that file (specifically, in mainFrame.OnRun())?
> 
> I don't know.
> 
> menuform.py parses the --interface-description xml data to create a
> properties dialog. The dialog takes the results of user choices and creates
> a command list for processing--ulitmately by cmd.Command.
> 
> > Even if you are determined to use that hack for the CLI, it has no
> > utility in regard to menus.
> 
> I just don't know if it is related to the p.mon, p.rast, etc scripts or
> whether it can simply be removed.

As a general rule, if no-one knows why something is there, then it
shouldn't be there.

It's understandable if something as old as GRASS has legacy code for
which the reason is unknown, but wxgrass shouldn't have reached that
point already.

-- 
Glynn Clements <glynn at gclements.plus.com>