> Michael Barton wrote:
>> 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.
>> 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)
> right now we have:
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
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
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
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/.
> for the others, probably one of:
> 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.
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 Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University