[GRASS-dev] GEM Wizard question
woklist at kyngchaos.com
Tue May 22 09:55:42 EDT 2007
You might want to take a look at what I did in the OSX app build -
macosx/app/build_html_user_index.sh and build_gui_user_menu.sh. Both
are run at startup. They could easily be made to work for all
platforms. The nice thing about these is that less configuration
needs to be done at install time, since they are dynamic.
On May 22, 2007, at 2:01 AM, Benjamin Ducke wrote:
> Actually, it's not much of a problem to introduce a new default and/or
> optional install prefix in GEM. The real trouble lies in two different
> areas, as far as I can think of right now:
> 1. The HTML man pages for the newly installed modules should be
> integrated into main HTML index. Currently, GEM manipulates the main
> HTML index in the install dir to do so. Of course, this requires
> superuser rights. The ideal solution would be to have a placeholder in
> the global HTML frontpage that will point to a subindex page
> present in
> the user's local extension directory. No idea how to do that in HTML
The user html index is separate from the main index. The GUI would
have to have a dynamic menu item for it so that it would have the
full path to the user's home. I initially tried ~ in the <a href>
and strangely it worked, but it turned out to be a Safari-only
thing. The global addon index is easy eanough, since it would not
change with the logged-in user.
I still need to work on g.manual and the non-GUI command dialogs (ie
when run without params) - they don't see the user help files yet.
I don't think Michael has a user help menu item in the GUI yet, but
the help index is still available in OSX since I have also integrated
it with the system help mechanism.
> 2. Many people like to have new GUI menu entries in gis.m when they
> install additional modules. This means that gis.m has to be
> prepared to
> look for additional menu entries in the current user's extension
> directory. This should not be too hard to do.
The script creates GEM-like menu files for the user commands. For
scripts I simply test for the #% Module tag, and for compiled modules
I use 'file' to check for binary executables (I assume a binary in
these locations is made for GRASS).
I mentioned this to Michael, but he hasn't worked it into the TclTk
GUI yet (I don't know any TclTk to try this). It should be just as
simple to do for the Python GUI.
> In principle, I agree that it would be much better to have locally
> installed extension. This could simplify the logics behing GEM a lot,
> too. It would also be possible to keep both the global and local
> installation schemes side-by-side, as a system-wide extension
> would probably also have its merits.
Just to make sure we're on the same wavelength, when I say 'global',
I mean a system location still external to the installed GRASS
application. Global just means all users can access it.
In effect, it's just like having in the installed GRASS, but on OSX
at least it's really preferable to have a separate global addon
location. I don't know what that would be in Windows, but on Linux
it might be something like /usr/local/share.
So, that would be 3 install location choices: application, global and
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
All generalizations are dangerous, even this one.
More information about the grass-dev