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

[Benjamin Ducke]

Whatever we do, I'd strongly argue for an approach that keeps
all differences between operating systems hidden from the user.

We should also aim for one unified mechanism and extension format,
as we will not be able to keep more than one supported in the long term.

Also, keeping complex, potentially cascaded menu entries in an
ASCII file makes it hard to parse that file, add (and delete,
update!) entries as necessary without corrupting the file structure,
duplicating or removing things accidentally etc. It involves creating
a customized parser from scratch.

The only approach I can think of to keep it file-based would be
to use an XML file database. We can use the GPL's libXML2 for that,
but this would mean introducing one more dependency to GRASS ;(

As an alternative, consider using folders and files to create the
menu structure:

- all the user needs to do is point GRASS to a top-level folder
for menu entries. Default, system-wide and user plug-ins folder
can easily be provided.

- the GUI than goes to that "master" folder and looks for subfolders.
Every folder inside the master is a new MENU entry (can be
n subfolders deep to allow cascading menus). Ascii files
inside a subfolder can represent simple menu ITEMS (one per
file). These will be added to the current menu level alphabetically
by file name (but item name as shown in the menu could be anything as
defined in the ascii file).

- adding entries for a new extension amounts to simply creating folders
inside the master folder. Removing them is just removing the folder(s).
Updating is just overwriting and existing folder (possibly first 
deleting the old one), etc. Very simple to do. Can all be handled
transparently using system's file commands.

- all the GUI needs to do is go thru the folders and subfolders and
piece together the menu cascades. Also very easy.

Benjamin


Michael Barton wrote:
> 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
>