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?
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?
Benjamin
Michael Barton wrote:
I just committed a new version of gmmenu.tcl, the GUI menu definition file.
This now will build an extension menu if GRASS_ETC_PATH is set and there
is a file named xtnmenu.dat in $GRASS_ETC_PATH.
xntmenu.dat is an ascii text file where each line has the format of...
main:<menu item name>:<executable name>:<menu item help text>
An item name of "separator" will create a horizontal line across the menu
Lines beginning with "#" are treated as comments and are ignored by the
menu building algorithm.
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
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
