On 9/24/07 9:11 AM, "Benjamin Ducke" <benjamin.ducke@ufg.uni-kiel.de> wrote:
This syntax makes sense, no doubt.
Question: How hard would it be to create the entire wxGRASS GUI menu
dynamically (i.e., not just an "Xtns" submenu), so that extensions could
registers new menu entries anywhere it makes sense in the menu bar?
The xtns submenu is not being created any more dynamically than any other
part of the menu. There is a data file of menu item, executable, help text,
and GUI procedure to run the executable. This is then parsed to create a
menu.
True dynamic menu creation would scan directories that house executables,
and automatically create and arrange menu items. Currently this is not
possible because there is no information stored with any executable that can
be used to get it placed correctly in the menu.
So at the moment, we're stuck reading some kind of menu data file.
Problem: Originally, currently GEM extensions install one menu
description file _per_ extension into a dedicated directory.
It was very easy for gis.m to pick up all files in that directory and
add entries to the "Xtns" menu in alphabetical order.
Also, the frontend for extension
installation (GEM) did not need to be concerned with reading, parsing
and writing menu descriptions. Copying the description file to the right
dir was enough. Updating amounted to overwriting and older version.
Now, we have one file for _all_ extensions. This means: writing a parser
for the frontend, thinking about updating, deleting, integrity checks
etc. to create and maintain a valid xntmenu.dat file.
-> Is that really necessary?
I understand. However, in GEM, there was a fair amount of code to parse
through the executable paths, gather up the executables, assign menu item
names, and then parse them into a TclTk list format.
I'm not sure that is any easier than creating a parser that can insert menu
item names, executable names, and help text into a simple ascii text file
(except of course you've already done all the work to achieve the original
menu parsing 
). You now ought to check for duplicate names, but then
someone has to do this somewhere in any case. It might as well be the
person/program that is creating menu entries.
The main problem with the prior GEM method, as a general approach, is that
it is specific to the executable file/directory structure of GEM. Also, it
involves nothing to make it co-exist with extensions put in by other means.
The idea of a single, general-purpose extensions manager/installer like you
and William are currently working out is highly desirable. However, IMHO, a
menu data file for user extensions should be transparent enough that a
packager can (with some coding) insert entries AND a user can insert custom
entries. There may be better ways to create a menu data file than the one
proposed (I remain open to suggestions), but it seems pretty straightforward
at least.
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