resolving more menu issues

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

resolving more menu issues

Michael Barton
resolving more menu issues I’ve come across a couple more menu issues that I’d like to propose solving in a general way that will work with multiple GUI’s

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?

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.

Thanks
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


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui