<HTML>
<HEAD>
<TITLE>proposal for grass extensions and addons</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>Benjamin and William,<BR>
<BR>
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.<BR>
<BR>
Anyone who wants to have extensions (binary modules or scripts) that show up in the menu, would need to...<BR>
<BR>
1) Put them in a directory and then make the directory visible to GRASS by adding it to GRASS_ADDON_PATH<BR>
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). <BR>
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.<BR>
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. <BR>
<BR>
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. <BR>
<BR>
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. <BR>
<BR>
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. <BR>
<BR>
How does this sound?<BR>
<BR>
Michael<BR>
__________________________________________<BR>
Michael Barton, Professor of Anthropology<BR>
Director of Graduate Studies<BR>
School of Human Evolution & Social Change <BR>
Center for Social Dynamics & Complexity<BR>
Arizona State University<BR>
<BR>
phone: 480-965-6213<BR>
fax: 480-965-7671<BR>
www: <a href="http://www.public.asu.edu/~cmbarton">http://www.public.asu.edu/~cmbarton</a> <BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>