[GRASS-dev] proposal for grass extensions and addons

[Michael Barton]

On 9/19/07 7:12 AM, "William Kyngesburye" <woklist at kyngchaos.com> wrote:

> On Sep 19, 2007, at 2:28 AM, Maris Nartiss wrote:
> 
>> Hi, just some comments inline.
>> 2007/9/19, Michael Barton <michael.barton at asu.edu>:
>>> 1) Put them in a directory and then make the directory visible to
>>> GRASS by
>>> adding it to GRASS_ADDON_PATH
>> IMHO there should be also one fixed add-on directory for system-wide
>> add-on's installed by root ($GISBASE/addons). Thus - root can install
>> add-on for all system users, user can install add-on only for self.
> 
> This should probably be left to a user/packager option - let them
> decide what it should be.  ie on OSX installing any extras directly
> in an app bundle is wrong.  Thus I currently have the GRASS startup
> for OSX (app build, not unix build) add an external global path to
> GRASS_ADDON_PATH.

Whatever directories used for extensions (fewer is better than more), it
should NOT be $GISBASE/[something].

Anything in $GISBASE will be overwritten with a binary install on Mac and
Windows (I'm not sure on Linux). It is better to have extensions live
outside of the main GRASS directory structure so that they persist through
updates.

It's OK with me to require a single directory name for all extensions, but
allow it to live in different places on different systems.

Probably the most flexible would be to allow extension modules to live
anywhere, as long as they are in GRASS_ADDON_PATH. A single menu def file
would live in GRASS_ADDON_EXT.

> 
> GEM already takes care of installing inside the GRASS distribution.
> 

This is a problem for binary installations.

>>> It would be easier to parse if everyone put the name of their
>>> extension(s)
>>> into the a SINGLE xtnmenu.dat file, shared by all (certainly my
>>> preference).
>>> But we should be able to deal with multiple xtnmenu.dat files, if
>>> need be,
>>> as long as they are all named xtnmenu.dat (or other standard) and
>>> all in a
>>> directory specified by GRASS_ADDON_PATH.
>> Single menu.dat (or whatever):
>> - single menu.dat (xtnmenu.dat) file requires user to use some menu
>> editor or digg into cryptic configuration file manualy to add new
>> add-on (if not some GEM-like feature is used).

No need to have cryptic configuration files. I like William's suggestion.
menu entry, command name, help text. Could be separated by commas or colons.
No need for anything else.

While the possibility of multiple menu def files avoids conflicts between
command names within a file, it doesn't help in overall function when you
actually try to run something. A single menu files would force people to
deal with it.

>> + User can have custom ordered menu instead of auto-generated one.
>> 
>> I'm not following closely to recent movement in GRASS_ADDONS and thus
>> have no idea how add-on directory looks like (wiki also has no entry
>> for it), but there could be two approaches (just thinking):
> 
> So far it's something I've worked out in the OSX app builds, but
> could easily be extended to other platforms (I just haven't been
> aggressive in pushing it to other platforms).
> 
>> In any way - if single menu conf file approach is choosed, then menu
>> editor is a must.

Not a *must* if the file is simple, but could be handy. Before a menu editor
(or even menu cascades) get worked out, we simply need to agree on a
protocol that can be implemented consistently.

>> 
> That's a nice idea - an extension menu editor in the GUI.  Probably
> should only be used for the user menu file (as I proposed having
> replying to Michael) and not for auto-generated menus.  Then the user
> wouldn't have to dig for the menu file.

After some reflection, I guess I'd rather see a single extension menu def
file that could be customized by users. The main reason is to avoid
conflicts. Anyone who has a system to automatically add entries to such a
file would have the responsibility to check for possible conflicts in menu
item and executable name. This would be easier in a single file than if
there could be multiple files.

Michael

> 
> 
> -----
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
> http://www.kyngchaos.com/
> 
> "I ache, therefore I am.  Or in my case - I am, therefore I ache."
> 
> - Marvin
> 
> 
> 

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton