[GRASS-dev] GEM Wizard question

[William Kyngesburye]

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  
> management
> 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  
user.

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

All generalizations are dangerous, even this one.