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

[Paul Kelly]

On Sat, 16 Jun 2007, Glynn Clements wrote:

>
> 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? I was thinking of 
changing g.mkfontcap to work like that. But I suppose, I could still do 
that and then it will be OK when run from a script or the command-line. 
Not so bad for the GUI to add a GUI stage to running the command I suppose 
- it just means an extra click of "Run".

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? 
It's not important anyway I suppose. But the point about over-riding the 
Tcl/Tk GUI box's run_cmd to store this history - that's in the gronsole I 
think - is important and helps to understand it a lot better, thanks.

Paul