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

[->dev list]

Michael Barton wrote:

I'd forgotten about this environmental variable. So I tried it out to
remind myself how it worked. Overall, it isn't much of an advantage,
at least in the case of r.reclass and absolutely will not work in the
TclTk GUI.

? try r.digit.

What is does is put the command back into the old interactive terminal
mode.

Only IF you don't don't enter the options at the command line.
No GUI means no GUI at all.

So for r.reclass, if GRASS_UI_TERM=0, you need to type ...

r.reclass input=[old_map] output=[new_map]

...to get to the interactive terminal screen where you can put in
reclass statements.

yes. and if you type "r.reclass" without options you get the GUI window,
which tries to output the terminal/curses "gui" in the gui output box.

If GRASS_UI_TERM=1 and you simply type r.reclass, you are prompted in
the terminal to enter the [old_map] and [new_map] before you can get
to the same terminal screen to put in reclass statements.

yes, but you don't get those prompts if you gave them on the command
line.

Because it requires interactive xterm use (query/response), it cannot
be used in the TclTk GUI platform.

Oh well.

?
no more than r.digit or any other module that is launched with
-command {term g.module }

It is a very useful module, IMHO, because it offers the chance to
maintain multiple views of a raster map and use only a tiny bit of
disk space.

it requires an term to run (like r.digit), but if fed reclass rules via
stdin it can run in non-interactive mode. e.g.

G63> r.reclass input=[old_map] output=[new_map] < rules.txt
G63>

I though this is what $GISBASE/gm/script/r.reclass.rules and
r.reclass.file for?

The problem:
r.reclass by itself on the command line launching a GUI breaks when you
hit [Run].

The solution: GRASS_UI_TERM=1 + wrapper scripts (wappers provide gui
frontend for gis.m with no breakage from the command line)
  $GISBASE/gm/script/r.reclass.rules and .../r.reclass.file

GRASS_UI_TERM=1 should not break your wrapper scripts.

?

Hamish

Correct.

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 (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). Then it requires the user
to type in file names from memory at an xterm prompt.

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.

I'm not saying that some people might not prefer to use the command this way
from the GRASS prompt. 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.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Hamish <hamish_nospam@yahoo.com>
Date: Thu, 9 Nov 2006 18:58:17 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5 <grass-dev@grass.itc.it>
Subject: Re: [GRASS-user] r.reclass not spawning xterm on Mac OS X

GRASS_UI_TERM=1 should not break your wrapper scripts.

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