William and Benjamin, This is fantastic progress on working out a straightforward, unified protocol to let users enhance their GRASS installations. I only have a few comments. Below.
On 9/20/07 3:05 PM, "Benjamin Ducke" <[EMAIL PROTECTED]> wrote: >>> 2. Integrating extension modules' HTML man pages into main index without >>> using the GRASS Make system >>> ... > It might be easier to create a second HTML index especially for > extensions which we can layout so that it becomes easier to parse for > our purposes. We could create a second GRASS script like g.manual.user > to display that index and put a not about it into the global HTML index. >> >> Though with all these GRASS_ADDON_* variables, I wonder if we should >> simplify them into just GRASS_ADDON_PATH which would be the base for >> structured dir with bin, lib, docs, etc subdirs. > > Yes. I would be in favour of that: one plugin dir for each user and > nothing more (to worry about). > I don't know how g.manual currently searches for the main GRASS doc directory, but it seems like it wouldn't be hard to change it to look in a doc directory within GRASS_ADDON_PATH. Like other extension files, this would survive a binary update on Mac and Windows. >> >>> 3. Binary installs >>> ... > > Also, extensions need to ship with different binaries for different > systems. We could try and guess the right ones automatically for the > user but I don't suppose there is a portable do of doing that. Binaries would be highly desirable for many users when possible. But whether or not they would get built should be up to the developer to hassle with. It isn't realistic to try to create a binary for all possible systems, but a limited number could cover a lot (e.g., RPM's, Debian, Mac, Windows). If you have a standard directory structure within a GRASS_ADDONS_PATH (e.g., make sure that path/bin is listed), it should make it easier to automatically install such binaries. 4. Back to menus You guys are working out all the hard stuff. But I'd like to go ahead and get a menu parser built in TclTk AND wxPython to deal with whatever you come up with. As a first go around, I'd still like to keep it a flat menu if you don't mind, so we can make it robust and reliable--and provide added value to your extension system. Thinking about it, more complex menu structure (submenus) should probably be done in the menu file rather than in a directory structure for the extension files themselves. The latter could get very complicated and messy. I don't think submenus would be all that difficult to implement eventually, but let's just start flat and see how it goes. Can I expect to find the following? 1) a SINGLE ascii menu file, named xtnmenu.dat 2) that can be found in the directory specified by GRASS_ETC_PATH 3) in which each line contains: "main:<menu item name>:<executable name>:<help text>" OR contains "main:separator::" Note the term 'main' as the first line of a xtnmenu.dat file line. The idea is that if we add submenus, we can replace 'main' by 'submenu', 'submenustart', or something along that line to do nested submenus. If this is OK, I'll craft a parser in gmenu.tcl with some dummy entries for you all to test. 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
