Michael Barton wrote: > 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. > 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. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
