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.
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
