[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.
..
> >> 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).
Hamish:
> > 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.

Michael:
> Here is my assessment FWIW. This applies to current GUI and new
> wxPython one


> (d.m could stay like it is)

right. (s/could/should/)
 

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

It's a work around easily done by a script in a one-liner call to
d.vect. Better done as a new flag in the module, e.g.:
  -d: draw input map as backdrop

For scripts which exist to overcome module deficiencies, I think it is
better to fix the module, not entrench the work-around as a formal
script. Or another way, there shouldn't be multiple scripts to do the
same task in a slightly different way- we are already up to ~392
modules- I have been using grass for a while now and still there are
still modules I have never heard of (e.g. I never noticed r.bitpattern
existed before a few days ago). Less noise is better.

keeping them in $SOMEWHERE/gui/scripts/ makes them stick out badly (as
you've noticed), which helps to motivate us to fix the real problem in
the module, gui code, or the libgis glue between them, rather than
perpetuate a work-around. Also, moving them to grass6/scripts/, then
deleting them later, clutters the ViewCVS interface with empty
directories (kept to store old attic history).


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

It performs a same technical task, but different conceptual task.
IMO send it to grass6/scripts/ like the v.centoids, v.dissolve,
v.what.vect scripts, as the module containing the functionality isn't
obvious.

> d.text.sh - Obsolete

if so, drop it.
 
> d.title.sh - Obsolete

We need to add a flag to d.title to call system(d.text) to make it
generally useful I think. Then we can drop this work-around script.
(regardless if it is used by the GRASS 6.x GUIs or is dropped for 7.x)

> print.sh _ ?????

No idea; if not used by the GUI I'd say drop it or if you have some need
for it then fully rewrite it.

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

it's redundant now with the new "r.colors rules=filename" and -i.
Can it be replaced by two menu items?


> 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)

it doesn't add new functionality, it just redirects from stdin.
Better handled by a new file= option as you say.

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

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

ditto.

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

still needed AFAIK-

> > 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?

bug created 10 months ago, so yes AFAIK. (if you mean new by Brad)


> v.in.asciipoints - Obsolete

ok. (does it even work? I see an unmatched quoting error)

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

It's just there to work around GUI + parser issues, and just waits for
GRASS 7 to be solved. No new functionality, keep it out of the main
scripts/.


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

After looking at them more, I still stand by that.


> 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.

if they only exist to make the GUI work inspite of misfeatures, then no,
don't put them in the general path. banish them elsewhere. they are
internal maintainance scripts not user scripts. aka if the misfeatures
didn't exist, neither would they.


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

No. Technical decisions and implementation are explicitly the domain of
the developers and consensus reached by the devels on this here
grass-dev mailing list.

RFC1 wrought:
"In general, once write access has been granted, developers are allowed
to make changes to the codebase as they see fit. For controversial or 
complicated changes consensus must be obtained on the developers'
mailing list as far as reasonably practicable. It is recognised that the
ultimate arbitration on technical issues should always lie with
consensus on the developers' mailing list. Specifically, it is not the
role of the PSC to impose technical solutions. Its role is in general
limited to enforcing the quality control mechanisms outlined above."

So the PSC's interest in the CVS server is primarily with making sure
that all commiters understand + heed the GPL, submitting guidelines,
etc.



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?


another thing to note is that wrapper scripts won't load the parent
module's help page. (eg v.type.sh, but there isn't much to say there)


Hamish