[GRASS-dev] proposal for grass extensions and addons

[Michael Barton]

Benjamin and William,

You both are trying to deal with the important concept of making easily
available additional extensions to the standard GRASS distribution. If this
can be made straightforward and consistent, we all hope that more people
will consider creating many binaries or scripts that can extend GRASS's
capabilities in new ways. As you both have indicated, it is desirable to
have any extension modules show up in the GUI menus to make them more easily
accessible to users.  Of course, any individual user may or may not have
extensions and the extension she/he does may vary from those of others. So
there needs to be a way of getting these into the GUI dynamically. Kind of
borrowing from both of your initial ad hoc solutions, I'd like to propose
the following way of dealing with extensions and getting them into the
menus. I'm also trying to use the structure already existing in GRASS to
avoid adding new complexities more than we need.

Anyone who wants to have extensions (binary modules or scripts) that show up
in the menu, would need to...

1) Put them in a directory and then make the directory visible to GRASS by
adding it to GRASS_ADDON_PATH
2) Create a simple text file named "xtnmenu.dat" the same directory as the
extensions (you all can suggest another name if you like, but it has to be
standardized). 
3) In xtnmenu.dat, list the executable names of each extension (i.e., the
name you would type on the command line to start it) with each name
separated from the others by a <newline>. All you need is the name. This way
the TclTk GUI OR wxPython GUI can build their respective menu entries as
they need them.
4) A special name, called "separator", would also be allowed to mark places
where the list of names is divided by a horizontal line from other names in
the menu. 

At startup, the GUI would scan any directories stored in GRASS_ADDON_PATH
searching for files named xtnmenu.dat. It would read each file and construct
a menu entry from each item in the list of items in the file.

If all the extensions are in directories listed in the path statement of
GRASS_ADDON_PATH, there is no need to worry about GRASS being able to find
them to execute. 

It would be easier to parse if everyone put the name of their extension(s)
into the a SINGLE xtnmenu.dat file, shared by all (certainly my preference).
But we should be able to deal with multiple xtnmenu.dat files, if need be,
as long as they are all named xtnmenu.dat (or other standard) and all in a
directory specified by GRASS_ADDON_PATH.

How does this sound?

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20070918/e53edefd/attachment.html