[GRASS-dev] resolving more menu issues

[Hamish]

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.

right now we have:

d.colors.sh
d.path.sh
d.shadedmap
d.text.sh
d.title.sh
print.sh
r.colors.rules
r.reclass.file
r.reclass.rules
r.recode.file
r.recode.rules
r.support.sh
v.in.asciipoints
v.type.sh


d.shademap is the only one I see there which might move to scripts/.


for the others, probably one of:
 $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. 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


Hamish