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
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
