[GRASS-dev] Re: [GRASSGUI] resolving more menu issues

[Glynn Clements]

Michael Barton wrote:

> 1. Currently, there are scripts that are only used (or only easily used) by
> the GUI. These reside in $GISBASE/etc/gm/script. The reason for these
> scripts is to overcome some inherent limitations of the interface to several
> important GRASS commands. For example, one script (r.colors.rules) allows
> you to chose the file for which you want to manage colors interactively
> through the GUI, then launches r.colors so that it opens an interactive
> xterm for setting color rules. Another provides a functional GUI interface
> to v.type without needing an interactive xmon. Yet another allows you to use
> the GUI to specify a reclassification file to send to r.reclass. You get the
> idea.
> 
> Having them buried in $GISBASE/etc/gm/script makes them more difficult for
> anything but the TclTk GUI to access these scripts. Some are primarily for
> the GUI, but others might be more broadly useful.
> 
> I propose either moving these to a new directory $GISBASE/scripts/gui and
> adding this as a path in init.sh OR simply moving them to $GISBASE/scripts.
> Several are now obsolete (e.g., d.text.sh and v.in.asciipoints) and could be
> removed. I¹d change the reference to them in the GUI (i.e., no longer
> necessary to specify a full path).
> 
> Is this OK with everyone?

I suggest using $GISBASE/scripts for anything which isn't inherently
limited to the GUI.

> 2. Related to this, I¹d like to make a couple more of the scripts obsolete
> if someone can help.
> 
> r.reclass and r.recode can use input files for reclass/recode rules. But the
> only way to get the file into either command is via a redirect. (e.g., [path
> to file] > r.reclass). Can a file= argument be added to both of these like
> it was recently added to r.colors? This would dispense with these scripts.

An alternative is to add stdin= and stdout= pseudo-options to the
module's GUI dialog, so that the user can redirect stdin/stdout of any
command from/to a file. This can be done in addition to a file= option
for modules where it would be useful.

However: any module which is run from the GUI must behave in a
non-interactive manner regardless of which flags/options the user
selects. Having the module hang because the user chose a combination
of options which results in the module trying to read from stdin isn't
acceptable.

You can probably eliminate hanging by simply closing stdin (or
redirecting it from /dev/null), although that may just result in a
different form of misbehaviour.

Ultimately, the only complete solution is to adopt (and enforce) a
policy that "modules" are never interactive. No exceptions. Absolutely
no exceptions whatsoever.

The last point won't happen before the 7.x branch comes into
existence, but I guarantee[1] that it will happen immediately
thereafter.

[1] Well, so long as I'm still alive, sentient, and have commit
access; if I can make it happen, I will.

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