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

[Michael Barton]

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 at 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 at lists.osgeo.org> wrote:
>> 
>>> 
>>> Message: 7
>>> Date: Wed, 12 Jan 2011 12:53:21 +0100
>>> From: Martin Landa <landa.martin at 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 at gmail.com>
>>> Cc: grass-dev at lists.osgeo.org
>>> Message-ID:
>>>        <AANLkTikVF+VdQKhNrDKPkfGX+4orKt+esiBQMzFc8JVu at mail.gmail.com>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>> 
>>> Hi,
>>> 
>>> 2011/1/12 Yann Chemin <yann.chemin at 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 at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> 
> 
> 
> 
> -- 
> Yann Chemin
> www.csu.edu.au