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

[Michael Barton]

William and Benjamin,

This is fantastic progress on working out a straightforward, unified
protocol to let users enhance their GRASS installations. I only have a few
comments. Below.


On 9/20/07 3:05 PM, "Benjamin Ducke" <benjamin.ducke at ufg.uni-kiel.de> wrote:

>>> 2. Integrating extension modules' HTML man pages into main index without
>>> using the GRASS Make system
>>> 
...
> 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.
>> 
>> 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).
> 

I don't know how g.manual currently searches for the main GRASS doc
directory, but it seems like it wouldn't be hard to change it to look in a
doc directory within GRASS_ADDON_PATH.

Like other extension files, this would survive a binary update on Mac and
Windows.

>> 
>>> 3. Binary installs
>>> 
...
> 
> Also, extensions need to ship with different binaries for different
> systems. We could try and guess the right ones automatically for the
> user but I don't suppose there is a portable do of doing that.

Binaries would be highly desirable for many users when possible. But whether
or not they would get built should be up to the developer to hassle with. It
isn't realistic to try to create a binary for all possible systems, but a
limited number could cover a lot (e.g., RPM's, Debian, Mac, Windows). If you
have a standard directory structure within a GRASS_ADDONS_PATH (e.g., make
sure that path/bin is listed), it should make it easier to automatically
install such binaries.

4. Back to menus

You guys are working out all the hard stuff. But I'd like to go ahead and
get a menu parser built in TclTk AND wxPython to deal with whatever you come
up with.

As a first go around, I'd still like to keep it a flat menu if you don't
mind, so we can make it robust and reliable--and provide added value to your
extension system.

Thinking about it, more complex menu structure (submenus) should probably be
done in the menu file rather than in a directory structure for the extension
files themselves. The latter could get very complicated and messy. I don't
think submenus would be all that difficult to implement eventually, but
let's just start flat and see how it goes.

Can I expect to find the following?

1) a SINGLE ascii menu file, named xtnmenu.dat
2) that can be found in the directory specified by GRASS_ETC_PATH
3) in which each line contains: "main:<menu item name>:<executable
name>:<help text>" OR contains "main:separator::"

Note the term 'main' as the first line of a xtnmenu.dat file line. The idea
is that if we add submenus, we can replace 'main' by 'submenu',
'submenustart', or something along that line to do nested submenus.

If this is OK, I'll craft a parser in gmenu.tcl with some dummy entries for
you all to test.

Michael


__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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