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 _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
