[GRASS-dev] GEM Wizard question

Tue May 22 11:13:23 EDT 2007

Since my time to work on GEM is very limited at the moment (basically none):

As far as menu entries are concerned, I'd opt for doing from the ground
up with the new wxPython GUI and just leave it the way it is for gis.m.
The ideal solution would be a directory-based inclusion mechanism: if a
directory exists in a certain place, then it will be scanned for menu
entries to add to the extensions menu.

HTML pages: with a built-in HTML Python widget, we could easily solve
the issue of global vs. local indices. For now, I'd just skip the HTML
installation and let users locate the manpages themselves.

Now, the only remaining question is where to store all extension files
(by default). We need a directory that work cross-platform (or at least
a unified way to figure out a user home directory on all supported
platforms; possible as a new function in the C API).

Michael Barton wrote:
> 
> 
> On 5/22/07 12:01 AM, "Benjamin Ducke" <benjamin.ducke at ufg.uni-kiel.de>
> 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
>>
>> 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.
>>
>> 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.
>>
>> Benjamin
> 
> Why not try to solve these issues one at a time. Having a simple way to
> create, install, and manage extensions would be a real plus and could
> stimulate use of the GEM system. IMHO, we should focus on getting this right
> and worry about the help files and menus a bit later.
> 
> To make life easier, why not simply keep the html help files with the
> extensions and have all extensions, by default, look for help files in the
> default extensions directory? Also, people can manually look at help files
> if they are in an easily accessible directory. A bit of an inconvenience,
> but users will be installing extensions of their choice and will have some
> idea of what they want.
> 
> I'm a big fan of GUI's and having commands listed on a menu so you don't
> have to remember them. BUT, getting extensions listed on the existing GUI
> menu system is a pain. To get the rest of the system in general operation,
> maybe just skip this. Since any extension will be installed by a user, who
> presumably will know what she/he installed, calling one or two from the
> command line won't be that much of a burden.
> 
> We can then think about better ways to get extensions into the menu. The
> menu system is being rethought anyway with the switch to wxPython, so we
> could design it with the possibility of extensions in mind if they become
> widely used and the details of how and where to install them get ironed out.
> For example, the menu could simply have an empty place holder for
> extensions. A menu-building function could then scan the default extensions
> directory to see if a menu file exists and use it to fill in the
> place-holder.
> 
> Michael
>> William Kyngesburye wrote:
>>> I've been meaning to ask about this root/external mod issue - is there
>>> any plan to support installation of GEM modules in a user dir?  More
>>> than just a problem of HOW to run this as root in the GUI, it's also a
>>> bit of a security problem and a platform standardization issue.
>>>
>>> On OSX, installing extras into an application binary is not the way
>>> things are done.  They should be installed in a standard
>>> plugin/extension location for the application - /Library so it is
>>> globally available to users, or ~/Library to make it available only for
>>> a single user.
>>>
>>> These locations act as extra GIS_BASEs, in effect - they have bin, lib,
>>> etc, doc... subfolders.  By use of standard GRASS env vars, they are
>>> easily included into the GRASS environment, and I recently added similar
>>> env vars and functions to locate external etc/ support files for modules
>>> that need it.
>>>
>>> For the OSX application build I've set
>>> [~]/Library/GRASS/$version/Modules as the global/user locations.  For
>>> now I have a separate module build template, much like GEM, but built
>>> modules must then be manually copied to one of these locations, since
>>> I'm too lazy to figure out alternate install targets in the makefiles.
>>>
>>> It would be nice to have GEM able to install in these locations at
>>> least, if not also arbitrary locations.  We would need to figure out
>>> good standard locations for other platforms also.
>>>
>>>
>>> On May 21, 2007, at 5:53 AM, Maris Nartiss wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm not following GEM development and thus have two silly questions:
>>>> 1) isn't possible to install additional modules via GEM into user's
>>>> home directory (as option)? Thus it could be made as easy as
>>>> installing some addons to Firefox.
>>>> 2) if getting superuser support for GUI right is lot of work, could
>>>> some GUI wizard just generate some commandline expression that could
>>>> be just pasted into terminal by user as last step to run it via su or
>>>> sudo?
>>>>
>>>> Just my 0.02.
>>>> Maris.
>>>>
>>>>
>>>> 2007/5/21, Benjamin Ducke <benjamin.ducke at ufg.uni-kiel.de>:
>>>>> I guess it wouldn't be too much trouble. GEM already has all that's
>>>>> needed for this: zipped extension packages can be downloaded (using
>>>>> wget), unzipped (to system's temp dir) and installed automatically.
>>>>> There is just one catch: since all files are installed into system-wide
>>>>> locations, the wizard will probably need superuser rights. So a tcl/tk
>>>>> based install wizard needs to provide a way to get the superuser
>>>>> password and run system commands with elevated rights.
>>> -----
>>> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
>>> http://www.kyngchaos.com/
>>>
>>> "History is an illusion caused by the passage of time, and time is an
>>> illusion caused by the passage of history."
>>>
>>> - Hitchhiker's Guide to the Galaxy
>>>
>>>
>>>
>>>
> 
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
> 
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
> 
> 
> 
> 

-- 
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg