Michael,
It seems that your latest changes have introduced a problem in the gis.m.
After going through the startup and entering GRASS, I get the message
can't read "menudatlist": no such variable
while executing
"foreach menudat $menudatlist {
I solved the issue for now by adding:
set menudatlist {}
at line 36 of gmmenu.tcl, but am not sure if that is the right approach
for solving this.
Moritz
Another problem (in addition to what Moritz found) - it's currently GRASS_ADDON_ETC, not GRASS_ETC_PATH. (and could change if we decide on a GRASS_XTN_PATH base path instead of multiple GRASS_ADDON_* vars)
And, for the cases where people do install addons in the GRASS installation, you might want to check for xtnmenu.dat in GISBASE.
Lastly, how about inserting a separator between xtnmenu.dat's, when there are multiple ones found? Sortof a visual cue that they are from different places.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history."
- Hitchhiker's Guide to the Galaxy
William and Moritz
On 9/23/07 1:25 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:
Another problem (in addition to what Moritz found) - it's currently
GRASS_ADDON_ETC, not GRASS_ETC_PATH.
I fixed both of these issues. Thanks for setting me straight.
(and could change if we decide
on a GRASS_XTN_PATH base path instead of multiple GRASS_ADDON_* vars)
I'd recommend keeping the xtnmenu.dat file in GRASS_ADDON_ETC because that
is already an existing GRASS environmental variable.
I'd also recommend using GRASS_ADDON_PATH for the same reason. Anything
listed in GRASS_ADDON_PATH will automatically run from the command line and
from in scripts (like the GUI) without an explicit path specification.
And, for the cases where people do install addons in the GRASS
installation, you might want to check for xtnmenu.dat in GISBASE.
No. This is the idea of a standard--so we don't have to check all the places
that people *might* try to put a menu file. If it is not in the standard
local (which is anywhere, but must be a place specified in GRASS_ADDON_ETC),
then it won't show up in the GUI.
Lastly, how about inserting a separator between xtnmenu.dat's, when
there are multiple ones found? Sortof a visual cue that they are
from different places.
Good idea. Done.
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
On Sep 23, 2007, at 7:40 PM, Michael Barton wrote:
(and could change if we decide
on a GRASS_XTN_PATH base path instead of multiple GRASS_ADDON_* vars)I'd recommend keeping the xtnmenu.dat file in GRASS_ADDON_ETC because that
is already an existing GRASS environmental variable.I'd also recommend using GRASS_ADDON_PATH for the same reason. Anything
listed in GRASS_ADDON_PATH will automatically run from the command line and
from in scripts (like the GUI) without an explicit path specification.
I don't mean the actual location of xtnmenu.dat would change, just the env variable used to locate it. Currently we have:
GRASS_ADDON_PATH - been around a while, should be left as is
GRASS_ADDON_ETC - fairly new addition
but will probably need soon:
GRASS_ADDON_HELP
And with the possibility of use the makefile fragments for building and installing extensions (I'm close), we will need to know where scripts/ and lib/ are.
My suggestion is to have one base for all this: GRASS_XTN_PATH (stil multiple paths). Then the various places that need them use subfolders (bin, lib, docs, etc, scripts) from there.
And, for the cases where people do install addons in the GRASS
installation, you might want to check for xtnmenu.dat in GISBASE.No. This is the idea of a standard--so we don't have to check all the places
that people *might* try to put a menu file. If it is not in the standard
local (which is anywhere, but must be a place specified in GRASS_ADDON_ETC),
then it won't show up in the GUI.
Just a thought.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
All generalizations are dangerous, even this one.
William
On 9/23/07 6:22 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:
I'd recommend keeping the xtnmenu.dat file in GRASS_ADDON_ETC
because that
is already an existing GRASS environmental variable.I'd also recommend using GRASS_ADDON_PATH for the same reason.
Anything
listed in GRASS_ADDON_PATH will automatically run from the command
line and
from in scripts (like the GUI) without an explicit path specification.I don't mean the actual location of xtnmenu.dat would change, just
the env variable used to locate it. Currently we have:GRASS_ADDON_PATH - been around a while, should be left as is
GRASS_ADDON_ETC - fairly new additionbut will probably need soon:
GRASS_ADDON_HELP
And with the possibility of use the makefile fragments for building
and installing extensions (I'm close), we will need to know where
scripts/ and lib/ are.My suggestion is to have one base for all this: GRASS_XTN_PATH (stil
multiple paths). Then the various places that need them use
subfolders (bin, lib, docs, etc, scripts) from there.
I understand what you are getting at and maybe this is the best way to go.
My point was simply that if you add another environmental path variable,
you'll have to make some changes (maybe in init.sh and maybe elsewhere) to
get an executable mapped to that path variable to actually run from the
command line or in a script. This is already done for GRASS_ADDON_PATH.
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