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

[Michael Barton]

Benjamin,

These all seem like good ideas as a directions to head.

I'd like to take this a step at a time, however, making sure that we keep
open the options to make the next step each time.


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

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

Definitely agree

> 
> 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 agree sort of. There are different ways of *making* extensions,
scripts, the GEM approach, William's makefile approach, and certainly
others. It's probably a good idea to settle on a limited number of these
(e.g., decide on the best way to compile a binary from source, and a best
way to distribute a binary, etc.).

But at the moment, I think it would be good to first focus on what we do
with extensions however we make them. For this, we need some kind of
standard that makes them easy to use from the command line and easy to run
as menu items in the GUI.

If we get this far, we can use the experience to go the next steps.

> 
> 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.

I agree here too. To begin with, let's just start with a protocol that will
generate a flat menu. We can try not to close off options to make this more
complex in the future. However, at the moment, there are not such a huge
number of extensions that this will be a problem in most cases.

> 
> 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 ;(

With the switch to wxPython, XML will become a viable option without any new
dependencies. Until then, it would be good not to introduce new dependencies
to the extent possible.

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

The folder structure is elegant for creating cascading menus. However, it
has some complications for actually holding extensions that can be
run--especially from the command line. If a directory holding an extension
is listed in GRASS_ADDON_PATH, it can be run by simply typing its name from
the command line. If you put extensions into a nested hierarchy of folders,
they would all have to go into GRASS_ADDON_PATH to run the extension from
the command line. This could quickly get unwieldy.

In addition to the automated way of creating menus when extensions are
installed by an instalation package like GEM, it seems a good idea to also
be able to support the user who makes a couple of special scripts and wants
to put them in an extensions directory and get them listed on the menu.

Michael

> 
> - 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
>> 
> 
> 

__________________________________________
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