[GRASS-dev] on the subject of toolboxes ...

[Hamish]

Hi,


before any work begins on this in earnest at the code sprint, I'd just
like to reiterate my take on the toolbox idea. i.e., (and insofar as I
understand the proposal as it exists!) any move towards splitting up
GRASS's build system and distribution package(s) would be a really
really huge mistake.


I would like to offer an alternate proposal which solves the same "new
user confronted with an overwhelming 747 cockpit of controls" problem,
but which does not splinter the core software.

Namely, implement "views" in the wxGUI preferences section, with
tick boxes where you can hide or show groups of modules as desired.
A core set of common modules would always be ticked in a greyed-out box,
and an "enable all" button would be present. Beyond that you can pick
and choose.

As our use cases vary widely, simply breaking up into "Core, Beginner,
Advanced" is too simplistic, and rather a grouping based on keyword
clusters (e.g. "remote sensing", "terrain analysis", ...) would be
more useful..


anyway, this needs to be discussed well before doing anything radical.



the problems as I understand people see them:

* As a by product of GRASS's enormous number of modules, the
discoverability and perceived learning curve can be a bit
overwhelming to new users.
   * Even as an advanced user, when you try to find something in the
menus there is a lot of scrolling past modules you don't use
(e.g. for me, wildfire modeling) which slows you down.

Both fair enough points, and hopefully with things like the wxGUI
module search tool, the module synopsis PDF, and optional "views"
of the menu tree we can go a long way to solving that.

[*] n.b. I'd still like to split the d.vect GUI button up into simpler
components (see d.stations, d.varea wrapper shortcuts in addons svn
for an idea of what I mean), in addition to the "kitchen sink"
advanced/full control access to the real module.


One of the major benefits of GRASS compared to other kitchen-sink GIS
is that you DON'T have to mess around with installing toolboxes. Every-
thing you need is there already.  We tend to take this for granted, but
it is a huge plus in our favour.  I came to GRASS after fighting for
years with installing additional Matlab and Arc toolboxes, and GRASS
was a huge breath of fresh air not to have to deal with that any more.
(and this problem hasn't gotten any better, I still have to deal with
and despise dongles and flexlm for proprietary toolboxes, and even
without having to deal with those there is always the DDL-hell, 32/64bit
versions, and missing libraries to deal with.. argh! & yay pre-packaged
everythings!)

In addition to that, I (and I suspect many of our users) spend a lot
of time out in the field, days away from any internet connection.
Even the most robust "Click here to install the missing component"
just doesn't work out there. Any often in the field you have to develop
workflows on the fly, so you can't really know what you'll need until
you get out there and the data starts coming in. And even when you think
you've prepared everything you could possibly need, the one thing you
can be sure of is that you haven't.

I know for me, the "already there" availability of GRASS modules
well outside the normal ones used in the common toolset/workflow
of my field of study has helped my career and my personal understanding
as a geoscientist enormously. It's the nexus of an interdisciplinary
approach with different folks from different fields all repurposing the
same tools for different ends and from different POVs. I think it is 
another thing we sort of take as normal around here, but really it is
an incredibly valuable and rare thing, and should be jealously guarded
with long ranting emails.



* Another argument given: The the base installer is too big.

Just to look at the (soon) Debian 64 bit package sizes:

 15K   grass_6.4.2-1_all.deb
             Meta-package, depending and recommending the rest

 11M   grass-core_6.4.2-1_amd64.deb
             The C, Python, and Shell libraries and modules

6.3M   grass-doc_6.4.2-1_all.deb
             The man pages and help page images

2.3M   grass-gui_6.4.2-1_amd64.deb
             The two Tcl/Tk GUIs, the WxPython GUI, NVIZ, xganim, etc

212K   grass-dev_6.4.2-1_amd64.deb
              The header and build files needed to build GRASS modules

 25M   grass-dev-doc_6.4.2-1_all.deb
              The GRASS Programmer's manual


So a typical install is under 20MB. This is incredibly small!, and no
problem even over slow/broken/expensive internet like we have down
here in the southern south Pacific.  Add max dependency software and you
approach the size of the MS Windows installer, 60MB. Still not so bad
considering the commercial alternatives come on DVDs and want gigabytes.

In short, the disk space / download-time argument is a non-issue. GRASS
is smaller than the onboard-video driver download for my new motherboard.
Users are more harmed by having to download (e.g.) six different files
than they are by having to download a single larger file, which possibly
contains some components which will go unused.




One final concern is that by relegating modules seldom used by the dev
team into what would essentially be second class toolboxes, those modules
will wither and die, and our more outside-of-the-mainstream users will
suffer for it.  --- We have a great position catering to niche users
who are not served by the other mainstream offerings. nurture them well!


So keep all modules installed, just give an option to focus the menus on
the relevant "toolkit(s)" of your choice.


comments? criticisms! both most welcome.. 


united we stand, divided we fall,
Hamish