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

[Glynn Clements]

Paul Kelly wrote:

> >>> 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.
> 
> Ah I see, I think. That sounds pretty important. But it does it mean that 
> tricks the module may do such as checking if there are any command-line 
> arguments before running G_parser() will be ineffective?

If you add --ui or --tcltk, an "argc > 1" check will pass, so
G_parser() will be invoked.

Such a check only makes sense if you have no required arguments. If
you have required arguments, the user will either have to enter them
or the command line or in the GUI dialog.

If the defaults for any optional arguments are good, adding a check
means that the user doesn't keep getting prompted for arguments where
the defaults will suffice. E.g. d.erase has the check, so "d.erase" is
equivalent to "d.erase color=white" rather than to "d.erase --ui".

OTOH, if it's unlikely that the user will want to simply accept the
defaults, the check should be omitted.

> I didn't realise gis.m worked like this too - might there be any value 
> then in removing the functionality that commands run from the command-line 
> pop up a GUI window when run with no arguments, i.e. behave as if 
> GRASS_UI_TERM was set? Was this behaviour only needed for d.m perhaps? 

The current behaviour was intended as an improvement over the
terminal-based Q&A dialogue; it wasn't designed with d.m or gis.m in
mind. The --ui option was added later to allow the "argc>1" check to
be bypassed, so that d.m could display a dialog for commands with such
a check. The --tcltk option was added to allow better integration with
gis.m.

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