[GRASS-dev] proposal for grass extensions and addons

William Kyngesburye woklist at kyngchaos.com
Wed Sep 19 10:12:50 EDT 2007


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.

GEM already takes care of installing inside the GRASS distribution.

>> 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).
> + 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.
>
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.


-----
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





More information about the grass-dev mailing list