[GRASS-dev] proposal for grass extensions and addons

[Maris Nartiss]

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.
>
> 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):
1) single directory for all add-on's.
  + no mess with different directories etc.
  - requires additional checks before adding new add-on does file
names not collide (like i.e. help.html)
2) directory per add-on. ($GRASS_ADDON_PATH/add-on_name/bin|etc|man|)
  + binary-compatible add-on's can be added just by untaring in to
$GRASS_ADDON_PATH;
  - mess with multiple directories;

In any way - if single menu conf file approach is choosed, then menu
editor is a must.

Did I missed how add-on icon is defined? If it's not used now, it
could be used in future.
>
> How does this sound?
Any attempt to standartize unclear GRASS areas is good.

>
> Michael

Sorry for interruption and my English,
Maris.