[GRASS-dev] d.rast.edit in wxgrass
Glynn Clements
glynn at gclements.plus.com
Sat Jun 16 16:06:51 EDT 2007
Paul Kelly 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 you're running the command from a GUI, it's preferable for the
dialogs to be generated by the GUI process rather than as a standalone
process.
E.g. if you select a command from gis.m's menus, gis.m invokes the
command using the --tcltk and evaluates the output (with certain
procedures overriden, e.g. run_cmd), rather than simply running the
command using --ui.
This has the advantage that the GUI gets to see (and optionally
modify) the arguments which were actually used, so that it can e.g.
record the complete command in a history list. If you just use --ui,
the re-invocation is hidden from the GUI.
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list