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