Re: [GRASS-dev] on the subject of toolboxes ...
On 20/05/12 03:51, Hamish wrote: 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. +1 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.. +1 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. Not just out in the field. We train people from countries where even power is not a certainty, and internet more a question of chance, even when they sit in their office. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] on the subject of toolboxes ...
Thanks Hamish for this discussion. Il 20/05/2012 03:51, Hamish ha scritto: > 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 think there are two issues here: - development cycle - distribution. I agree warmly that distribution should make life as easy as possible for users, so a single package (standalone installer) is the main way to go. As for development, I think splitting the release cycle of GUI and CLI would be advisable, as they have different cycles, speed of development, and dependencies. More clearly: if a [new|fixed|improved] command is ready, and its native GUI is not, are we sure we want to keep this away form users that can profit form this using the CLI or a different GUI? > 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. I find filtering (as done in QGIS and in Sextante) quite simple and useful. Adding tagging would be enough IMHO. Views could be interesting. > 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. Agreed - that's why I'm still uncomfortable with addons (even though I understand its rationale). > In short, the disk space / download-time argument is a non-issue. Agreed fully. Modularity, however, is always a Good Thing (e.g., I appreciated very much your splitting because I do not want to install GUI stuff on a server, etc.). > 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. Agreed. > comments? criticisms! both most welcome.. Hoe this mine will be useful. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] on the subject of toolboxes ...
+1 From: grass-dev-boun...@lists.osgeo.org [grass-dev-boun...@lists.osgeo.org] on behalf of Sylvain Maillard [sylvain.maill...@gmail.com] Sent: Sunday, May 20, 2012 4:00 PM To: Hamish Cc: grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] on the subject of toolboxes ... Hi dev's, 2012/5/20 Hamish mailto:hamis...@yahoo.com>> 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 a user I fully apply to this proposal ! that's already how it works in some other software like QGis or Drupal, and everyone seems to like it ... I see an other good reason for this choice: it would be possible to have a box with the full index of modules and some explanations (like on the web manual), I think it will help new users to find the module they need ! cheers, Sylvain ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] on the subject of toolboxes ...
Hi dev's, 2012/5/20 Hamish > > 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 a user I fully apply to this proposal ! that's already how it works in some other software like QGis or Drupal, and everyone seems to like it ... I see an other good reason for this choice: it would be possible to have a box with the full index of modules and some explanations (like on the web manual), I think it will help new users to find the module they need ! cheers, Sylvain ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] on the subject of toolboxes ...
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 ar
