[GRASSGUI] resolving more menu issues

[Michael Barton]

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: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-gui/attachments/20070609/3502d1d9/attachment.html

[Glynn Clements]

Post by Michael Barton
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.

Post by Michael Barton
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.

[Michael Barton]

Post by Michael Barton
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.

..

Post by Michael Barton
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).

Yes, it would be nice to move generic wrapper scripts which are just
needed for a GUI/core interaction (ie nothing to do with tcl or wx)
from gui/tcltk/gis.m/script/ to gui/script/ or somesuch place.

Here is my assessment FWIW. This applies to current GUI and new wxPython one
(d.m could stay like it is)
d.colors.sh - Obsolete

d.path.sh - Of general use (more useful for GUI, but also for scripting)

d.shadedmap - Of general use (simple way to do same thing with d.his)

d.text.sh - Obsolete

d.title.sh - Obsolete

print.sh _ ?????

r.colors.rules - Of general use (GUI for picking map; will be obsolete with
wxgrass)

r.reclass.file- Of general use, but would be unnessary with a file= option
r.reclass.rules- Of general use (GUI for picking map; will be obsolete with
wxgrass)

r.recode.file- Of general use, but would be unnessary with a file= option

r.recode.rules- Of general use (GUI for picking map; will be obsolete with
wxgrass)

r.support.sh - Obsoletes (maybe not??)

v.in.asciipoints - Obsolete

v.type.sh- Of general use (should effectively replace GUI for v.type)

d.shademap is the only one I see there which might move to scripts/.
$GISBASE/etc/gui/scripts/
$GISBASE/scripts/gui/
$GISBASE/scripts/
Personally, I favour $GISBASE/etc/gui/scripts/. You shouldn't add
anything init.sh, just change the existing references to
$GB/etc/gm/scripts/ to the new place.

One objective would be to allow any of these to be run by simply typing
their name, without the full path. To do this, they would need to go into a
directory already listed in the PATH in init.sh or to add the new directory
to the PATH in init.sh.

I don't think there is anything

complicated there to worry about losing the CVS history by moving the
file in CVS to grass6/gui/scripts/. The history was already cropped when
copied from d.m. Maybe add a comment in the CVS checkin message about
their migration from d.m/scripts/ to gis.m/scripts/ to the new spot, so
there is a trail to follow if someone wants to track a history.
And of course these all exist due to deficiencies in modules, which
should be fixed directly; and any outdated scripts should be removed.
Note r.support.sh works around a very weird bug where the module quits
after only the first few [y/N] questions in the xterm.
https://intevation.de/rt/webrt?serial_num=5094

Even the new and improved r.support?

Do I need PSC OK to make this kind of change to the cvs structure after
we've worked it out?

Michael



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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Glynn Clements]

Is everyone happy with putting the relevant gui scripts in
grass6/gui/scripts/ in the source code and then $GISBASE/etc/gui/scripts/
after "make"? Or have a better idea?

If there's even a remote possibility that the script would be useful
from the command line, it should be installed in $GISBASE/scripts
(which is in $PATH).

[Michael Barton]

Thanks. Are the menu references to these changed too?

Now that I'm back, I hope to make r.reclass.rules and r.recode.rules
obsolete for TclTk like I did for wxPython. I'm hoping that r.reclass.file
and r.recode.file can be made obsolete with slight changes to the C-modules
too.

Michael

it would be nice to move generic wrapper scripts which are just
needed for a GUI/core interaction (ie nothing to do with tcl or wx)
from gui/tcltk/gis.m/script/ to gui/scripts/

Now done for non-obsolete scripts. After install they live in
$GISBASE/etc/gui/scripts/.
d.shadedmap moved to the main script/ dir, now it's a normal module.
I added a -d flag to d.title to run G_system(d.text) automatically, so
d.title.sh is now obsolete.
the rest of the GUI wrapper scripts should be removed once the modules
- r.reclass, r.recode, r.colors, take input from a file= option as an
alternative to stdin; better- write a GUI to help make the input file
then run r.reclass with that)
- d.path has a coor= option now, so it can be used non-interactively.
i.e. the GUI can pick the two coords interactively and then run the
module non-interactively and display the result.
- The r.support bug is still weird. (breaks out after two [y/n]
questions if run directly in an xterm)
hopefully no problems,
Hamish

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton