Markus N wrote: > > since the r.stream.* modules are continuously requested > > and IMHO sufficiently tested (according to user reports), I > > would move them to core if there are no objections. > > Coming back to this topic (delayed due to my "outage" in > winter): no objections, it seems.
I would be happy to see r.stream.* become part of the core. At the risk of hijacking the thread, for those concerned that the menus look like a 747 cockpit of options and so are not user friendly, I'd again suggest a solution of "GUI views" settable from the preferences menu, to hide or show different menu items. >From work packaging for debian, and from work trying to get g.extension working for everyone everywhere, the idea of breaking the core up into lots of addon toolboxes really makes me shudder. Not having to fight with out-of-sync toolboxes is one of the reasons I switched to GRASS in the first place :), and I've gotten at least two papers out of easy access to modules which performed processes that were typically not used in my field of study, which I otherwise may never have looked at. I didn't get much feedback about the "GUI views" idea before, but I'd still like to hear thoughts about the approach. ? Very much straying offtopic now, I'd also advocate a series of wrapper scripts to run from GUI buttons for simple-mode d.vect. (see also my d.* helper/wrapper scripts in g6 addons like d.varea, d.stations, and d.mark) I feel the current d.vect GUI window is a bit overwhelming, but that's no reason to break up the base module, since wrapper scripts can handle the "simple views", and the full d.vect module gui could be there for "advanced" mode. > r.regression.* might be another trunk candidate set. > > Overview: > http://grasswiki.osgeo.org/wiki/AddOns/GRASS_7 I've no experience with r.regression.* as I don't do that much multi-spectral stuff, but if MarkusM was the author that's good enough for me wrt the code quality side of things. wrt the "how esoteric is it?" side of things, in general I'd say low-level tools/building blocks suitable for multiple purposes and useful as intermediary steps in scripts are a good match for 'core'. re. other modules to consider- One day I'd like to put the finishing touches on d.barb in g6 addons and then port it to g7 with an eye to getting it into g7 core for its d.rast.arrow-for-vectors capabilities. time, time, time.. best, Hamish _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
