[GRASS-dev] Re: [GRASS-user] r.reclass not spawning xterm on Mac OS X

[Hamish]

Michael Barton wrote:
> 
> But I don't see any gain in usability from the GUI. We could set
> GRASS_UI_TERM=1 and then run r.reclass in a terminal window. But this
> still needs a script of some kind to launch
[from the GUI]

but you already wrote one, (well, two). yes, keep them,

> (at least for...saving the current value of GRASS_UI_TERM, setting it
> to 1, running r.reclass, resetting GRASS_UI_TERM back to whatever it
> was originally).

no.

by starting the module with:

GRASS_UI_TERM=1 r.reclass

or having G_putenv("GRASS_UI_TERM","1"); in the start of the C code, you
only change the value for the running module, not for the session.

Child proccesses can't change variables in their parent's environments.
When the child exits, all changes to vars vanish with it.

(see also export VARIABLE")

> Then it requires the user to type in file names from memory at an
> xterm prompt.

FWIW, "list" at the prompt will work.

I do g.list + cut & paste all the time while composing command line
options...


> Currently, we use a script and take advantage of the GRASS parser to
> allow the user to browse for an existing file and type a new file name
> into a completely editable entry widget.

yes, and this is very nice.
 
> I'm not saying that some people might not prefer to use the command
> this way from the GRASS prompt.

from the command line the GUI just won't work without the wapper
scripts or without command line options specified.

> And it is nice that this option exists. It's just that it doesn't make
> it any easier to run r.reclass within the GUI.

the wrapper scripts set the full input= and output= options, so the UI
setting when set WITHIN the r.reclass C child won't affect it. When set
BEFORE running the wrapper script, it'll nuke the wrapper script's GUI
as well. So we put it in the C module or within the wrapper script.



Hamish