[GRASS-dev] Re: proposal for grass extensions and addons

[William Kyngesburye]

On Sep 20, 2007, at 5:05 PM, Benjamin Ducke wrote:

>>> 2. Integrating extension modules' HTML man pages into main index  
>>> without
>>> using the GRASS Make system
>>>
>> Right now, I use a separate help index from the installed/built  
>> one.  I don't think there is a way with basic HTML files to  
>> dynamically include other html files.  It could work if there was  
>> a local webserver, but that's not something we can count on.
>
> Right, GEM currently used a lot of HTML file parsing to manipulate the
> main index.html (it looks for a special commented in there in order
> to find the place to append its own index). However, for user  
> installs,
> we need a local HTML index, which needs to be linked to the system- 
> wide
> HTML index (however, in order to manipulate that one, we again would
> need superuser rights -- aargh!).
>
The problem with having ANY link in the built/installed help index to  
a user index is that the URL for every user to their home folder is  
different.  You can't use $HOME/ or ~/ in URLs (though I found that  
it does work in Safari, but that's an exception).


> It might be easier to create a second HTML index especially for
> extensions which we can layout so that it becomes easier to parse for
> our purposes. We could create a second GRASS script like g.manual.user
> to display that index and put a not about it into the global HTML  
> index.

My OSX index generator does this (the creation part).  See macosx/app/ 
build_html_user_index.sh.  But we shouldn't need a separate  
g.manual.user, g.manual should figure it out.  For individual pages,  
it would look in dirs specified in GRASS_ADDON_HELP (or some such  
path variable), then the GRASS binary package.  The first path it  
finds it in would be passed as the URL to the help browser.

For the index, that's a bit tricky from g.manual.  Each path in the  
hypothetical GRASS_ADDON_HELP could have an index.  So asking it to  
show the "user" index could be ambiguous.  At least in the GUI, as  
many menu items can be used as are needed.


>> Though with all these GRASS_ADDON_* variables, I wonder if we  
>> should simplify them into just GRASS_ADDON_PATH which would be the  
>> base for structured dir with bin, lib, docs, etc subdirs.
>
> Yes. I would be in favour of that: one plugin dir for each user and
> nothing more (to worry about).
>
Restricting the number of addon dirs may simplify the whole thing (1  
global, 1 user per user).  But that's not quite the same flexibility  
that the rest of GRASS has. ie multiple paths are possible in  
GRASS_ADDON_PATH (as it is used currently), and the user is free to  
add to it.  Glynn and others could probably expand on this.


-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.