[GRASS-dev] Re: [GRASS-SVN] r44977 - in grass/trunk: gui/wxpython/xml imagery imagery/i.evapo.PT

GRASS GRASS developer
1

Having user-installable toolboxes is a nice idea in theory. But there are at least 2 important pragmatic issues to be addressed

1) Installing these over Linux is a different thing than installing them in Windows or on the Mac. I haven't tested the extension module recently (i.e., last 6 months), but it didn't work for Mac and I don't know if it has worked reliably for Windows. Also note that on the Mac, you cannot compile things unless you install the Developer Tools, something most people don't install (or even know about) by default. To make separate and smoothly installable packages of optional tools, we would need to maintain them in binary form for users to install from somewhere. Something that works as smoothly as FireFox extensions is what we should aim for. Even OpenOffice extensions sometime have installation bombs.

2) There is not yet any consensus on what constitutes "core" tools. We need to have a discussion that goes beyond the developer group on this. What the developers think are core might not be to a larger user base.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jan 12, 2011, at 10:00 AM, <grass-dev-request@lists.osgeo.org> wrote:

Message: 7
Date: Wed, 12 Jan 2011 12:53:21 +0100
From: Martin Landa <landa.martin@gmail.com>
Subject: Re: [GRASS-dev] Re: [GRASS-SVN] r44977 - in grass/trunk:
       gui/wxpython/xml imagery imagery/i.evapo.PT
To: Yann Chemin <yann.chemin@gmail.com>
Cc: grass-dev@lists.osgeo.org
Message-ID:
       <AANLkTikVF+VdQKhNrDKPkfGX+4orKt+esiBQMzFc8JVu@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2011/1/12 Yann Chemin <yann.chemin@gmail.com>:

(Thx, did not read that one yet, so did now)

I would tend to agree with Jarek too.

The use of Module keywords should facilitate the three layers
mentioned, and maybe special keywords like "core", "toolbox",
"experimental" could permit three levels of compilation of GRASS GIS
(Basic, Advanced, Dev).

user should have possibility to easily install

1) whole toolboxes, eg. `g.toolbox toolbox=hydrology` would install
all modules related to hydrology

2) modules, eg. g.extension extension=r.stream` would install only
given module (or it could be integrated in g.toolbox)

Of course we could distribute packages with common toolboxes like now
we are doing. I think it would make development more transparent. The
core would contain only libs and small subset of modules with high
stability (grass/trunk), toolboxes maintained and stable modules
(grass-tools/trunk) and the reset could be in grass-addons.

Martin

--
Martin Landa <landa.martin gmail.com> * Studijní program Geodézie a kartografie – GeoWikiCZ

2

What about changing the displayed menus available?
i.e. compile all, but have menu only change, it should be lighter to
do on wxpython than changing compiling processes.
You could then select an hydrology toolbar to appear additionally to
the "core" toolbar.

On 13 January 2011 05:11, Michael Barton <Michael.Barton@asu.edu> wrote:

Having user-installable toolboxes is a nice idea in theory. But there are at least 2 important pragmatic issues to be addressed

1) Installing these over Linux is a different thing than installing them in Windows or on the Mac. I haven't tested the extension module recently (i.e., last 6 months), but it didn't work for Mac and I don't know if it has worked reliably for Windows. Also note that on the Mac, you cannot compile things unless you install the Developer Tools, something most people don't install (or even know about) by default. To make separate and smoothly installable packages of optional tools, we would need to maintain them in binary form for users to install from somewhere. Something that works as smoothly as FireFox extensions is what we should aim for. Even OpenOffice extensions sometime have installation bombs.

2) There is not yet any consensus on what constitutes "core" tools. We need to have a discussion that goes beyond the developer group on this. What the developers think are core might not be to a larger user base.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jan 12, 2011, at 10:00 AM, <grass-dev-request@lists.osgeo.org> wrote:

Message: 7
Date: Wed, 12 Jan 2011 12:53:21 +0100
From: Martin Landa <landa.martin@gmail.com>
Subject: Re: [GRASS-dev] Re: [GRASS-SVN] r44977 - in grass/trunk:
gui/wxpython/xml imagery imagery/i.evapo.PT
To: Yann Chemin <yann.chemin@gmail.com>
Cc: grass-dev@lists.osgeo.org
Message-ID:
<AANLkTikVF+VdQKhNrDKPkfGX+4orKt+esiBQMzFc8JVu@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2011/1/12 Yann Chemin <yann.chemin@gmail.com>:

(Thx, did not read that one yet, so did now)

I would tend to agree with Jarek too.

The use of Module keywords should facilitate the three layers
mentioned, and maybe special keywords like "core", "toolbox",
"experimental" could permit three levels of compilation of GRASS GIS
(Basic, Advanced, Dev).

user should have possibility to easily install

1) whole toolboxes, eg. `g.toolbox toolbox=hydrology` would install
all modules related to hydrology

2) modules, eg. g.extension extension=r.stream` would install only
given module (or it could be integrated in g.toolbox)

Of course we could distribute packages with common toolboxes like now
we are doing. I think it would make development more transparent. The
core would contain only libs and small subset of modules with high
stability (grass/trunk), toolboxes maintained and stable modules
(grass-tools/trunk) and the reset could be in grass-addons.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Yann Chemin
www.csu.edu.au

3

Maybe, but altering the menus in this way is not as easy as it might seem. Also, I don't quite see the point of installing functionality and then hiding it from the user.

It seems better to me to think about how we can present additional functionality to the user. Martin's idea of a toolbox is attractive in this respect. I'm not sure how that would actually be implemented in reality, but there are a variety of ways to go with that. It also allows for open-ended enhancements while maintaining a consistent user interface to enhancements.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jan 12, 2011, at 3:24 PM, Yann Chemin wrote:

What about changing the displayed menus available?
i.e. compile all, but have menu only change, it should be lighter to
do on wxpython than changing compiling processes.
You could then select an hydrology toolbar to appear additionally to
the "core" toolbar.

On 13 January 2011 05:11, Michael Barton <Michael.Barton@asu.edu> wrote:

Having user-installable toolboxes is a nice idea in theory. But there are at least 2 important pragmatic issues to be addressed

1) Installing these over Linux is a different thing than installing them in Windows or on the Mac. I haven't tested the extension module recently (i.e., last 6 months), but it didn't work for Mac and I don't know if it has worked reliably for Windows. Also note that on the Mac, you cannot compile things unless you install the Developer Tools, something most people don't install (or even know about) by default. To make separate and smoothly installable packages of optional tools, we would need to maintain them in binary form for users to install from somewhere. Something that works as smoothly as FireFox extensions is what we should aim for. Even OpenOffice extensions sometime have installation bombs.

2) There is not yet any consensus on what constitutes "core" tools. We need to have a discussion that goes beyond the developer group on this. What the developers think are core might not be to a larger user base.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jan 12, 2011, at 10:00 AM, <grass-dev-request@lists.osgeo.org> wrote:

Message: 7
Date: Wed, 12 Jan 2011 12:53:21 +0100
From: Martin Landa <landa.martin@gmail.com>
Subject: Re: [GRASS-dev] Re: [GRASS-SVN] r44977 - in grass/trunk:
       gui/wxpython/xml imagery imagery/i.evapo.PT
To: Yann Chemin <yann.chemin@gmail.com>
Cc: grass-dev@lists.osgeo.org
Message-ID:
       <AANLkTikVF+VdQKhNrDKPkfGX+4orKt+esiBQMzFc8JVu@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2011/1/12 Yann Chemin <yann.chemin@gmail.com>:

(Thx, did not read that one yet, so did now)

I would tend to agree with Jarek too.

The use of Module keywords should facilitate the three layers
mentioned, and maybe special keywords like "core", "toolbox",
"experimental" could permit three levels of compilation of GRASS GIS
(Basic, Advanced, Dev).

user should have possibility to easily install

1) whole toolboxes, eg. `g.toolbox toolbox=hydrology` would install
all modules related to hydrology

2) modules, eg. g.extension extension=r.stream` would install only
given module (or it could be integrated in g.toolbox)

Of course we could distribute packages with common toolboxes like now
we are doing. I think it would make development more transparent. The
core would contain only libs and small subset of modules with high
stability (grass/trunk), toolboxes maintained and stable modules
(grass-tools/trunk) and the reset could be in grass-addons.

Martin

--
Martin Landa <landa.martin gmail.com> * Studijní program Geodézie a kartografie – GeoWikiCZ

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
grass-dev Info Page

--
Yann Chemin
www.csu.edu.au

4

Michael Barton wrote:

Having user-installable toolboxes is a nice idea in theory. But
there are at least 2 important pragmatic issues to be addressed

3) In 7.0, anything not in the main repository will be prone to
bit-rot as the API changes. If a developer changes an API, they can
reasonably be expected to fix any modules which used that API, but
this doesn't hold for add-ons.

--
Glynn Clements <glynn@gclements.plus.com>

5

Good point, stll other software projects manage it somehow.
* Stricter rules for API changes
* API version checks
* API Changelog with HowTo migrate hints.

Nothing impossible, just a bit of rules and enforcing. R manages
somehow to have gazzillion of addons with easy install - can we borrow
ideas there?

Still - is it worth to NOT have lots of modules in core? Confusion
could be reduced by toolbox-like naming, better GUI menus and search
etc.

Just keeping mind open for other options,
Maris.

2011/1/13 Glynn Clements <glynn@gclements.plus.com>:

Michael Barton wrote:

Having user-installable toolboxes is a nice idea in theory. But
there are at least 2 important pragmatic issues to be addressed

3) In 7.0, anything not in the main repository will be prone to
bit-rot as the API changes. If a developer changes an API, they can
reasonably be expected to fix any modules which used that API, but
this doesn't hold for add-ons.

--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

6

Hi,

2011/1/12 Michael Barton <Michael.Barton@asu.edu>:

1) Installing these over Linux is a different thing than installing them in Windows or on the Mac. I haven't tested the extension module recently (i.e., last 6 months), but it didn't work for Mac and I don't know if it has worked reliably for Windows. Also note that on the Mac, you cannot compile things unless you install the Developer Tools, something most people don't install (or even know about) by default. To make separate and smoothly installable packages of optional tools, we would need to maintain them in binary form for users to install from somewhere. Something that works as smoothly as FireFox extensions is what we should aim for. Even OpenOffice extensions sometime have installation bombs.

sure, first step is to make g.extension solid...

2) There is not yet any consensus on what constitutes "core" tools. We need to have a discussion that goes beyond the developer group on this. What the developers think are core might not be to a larger user base.

Feel free to discuss at
http://grass.osgeo.org/wiki/GRASS_repository_layout_proposal

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa