Maciek,
Previously these things all worked (except for r.resamp.rst, which is new
since I finished the menus late last Spring). I am guessing that changes to
the grass parser modules implemented over the summer have caused some of the
tcltkgrass modules in 5.3 to fail now.
To the list in general, it seems that a command with a flag will no longer
parse correctly in the tcltkgrass modules for 5.3. The odd thing is that
other arguments (at least one that I tried) do seem to parse OK. In a number
of cases, the flags were included with the command as a convenience.
I can add them as user options in the modules affected (I don't remember
which or how many at the moment), but does anyone have a clue why these are
not parsing now? The format is:
interface_build {
{s.to.vect -p} 0
{Converts a GRASS sites map to a GRASS vector map.}
{entry input {Name of input site list:} 0 sites}
{entry output {Name of new vector file:} 0 vector}
{entry cat {String field in site_list to use in vector file
(default=1):} 0 ""}
}
It seems that the command string in brackets {s.to.vect -p} ought to parse
OK. Quoting it seems redundant. Any thoughts?
With respect to the scrolling, this is indeed an annoyance. It is NOT a
problem in GRASS 5.7 where module dialogs automatically scroll vertically or
horizontally as needed. There is a vertical scroll widget defined in gui.tcl
of tcltkgrass for 5.3, but I couldn't get it to work with modules. Perhaps
someone else would have better luck.
Michael
On 9/28/04 2:50 AM, "Maciek Sieczka" <werchowyna@pf.pl> wrote:
Michael,
thanks for fixing things
below I'm giving some comments and some more bugs I've found in the
tcltkgrass2. After choosing GIS->Map type conversions->Sites to vector I'm
getting: couldn't execute "s.to.vect -p": no such file or directoryFixed. Added option to enter or not enter metadata on new vector points
created. To do this, s.to.vect now opens in an xterm where you can enter
metadata if the -p flag is not checked."d.measure -s" also gives "couldn't execute (...)"
possible that more modules with a fixed "-" may behave the same if there are
anyIMO it uses a much different algorithm than s.surf.rst or v.surf.rst.
The only raster module utilizing regularized spline with tension is
r.resamp.rst (it'd be nice to have it in the tcltkgrass by the way).how about about this module for r.resamp.rst some day?
3. There is no entry for v.surf.rst in the vector menu - only in the
raster menu.Added module (already written by someone else) for v.surf.rst. Note that a
couple of options (anisotrophy and another) are left out because the
module is already as large as my screen and may not show up completely
on lower resolution screens. I don't know why there is not an option for a
vertical scroll-bar in the 5.3 menu module builder, but the modules are
limited (practically) to the vertical screen resolution.in general this a pain
even if working in 1024x768 (which is not low I think) still some of the
menus are not visible in full extent
BTW it also considers the NVIZ (I put a bug report on this)It may be recognized as a not very important issue but as to me it is a
bug - since tcltkgrass is supposed to be GUI and NVIZ means for
visualization as well then they should be fully functional according to all
the graphics features they put on the screen for the user.I understand that there are technical limitations in what can be done using
the tcltk but for as a user I only see a bug which should be fixed.BTW - what is the r.surf.idw2 for anyway when it is slower, less
universal and gives identical results. Strange... Ask Grass developers?I don't know what the difference is either.
Can anybody say if there are any more diffrences between the r.surf.idw2
and *idw which justify both them being available?and here a few more bugs:
1. r.surf.area should be r.surf.fractal propably because the output is:
Sorry, <out> is not a valid parameter
Sorry, <d> is not a valid parameter
Sorry, <n> is not a valid parameterERROR: Required parameter <input> not set:
(Raster file for surface.).Description:
Surface area estimation for rasters.Usage:
r.surf.area input=name [vscale=value]Parameters:
input Raster file for surface.
vscale Vertical scale2. Something's wrong with the r.surf.gauss. When anything given for
"Gaussian distribution mean" got:Sorry, <d> is not a valid parameter
(...)
Usage:
r.surf.gauss out=name [mean=value] [sigma=value]Parameters:
out Name of the random surface to be produced
mean Distribution mean
default: 0.0
sigma Standard deviation
default: 1.03. If any "xyz" button pressed in the "d.3d" menu the result is as you can
see on the attached d3d_xyz.png. It's been the same since the first Grass
5.0 I've ever used .4. "3d.views" doesn't work because there is no such thing in Grass 5.3 but
there is "3d.view.sh" which you propably mean.5. After "OK" In the "Module font" I'm getting:
bad window path name ".s_proj"
bad window path name ".s_proj"
while executing
"winfo children $path"
(procedure "children" line 3)
invoked from within
"children $path"
(procedure "setfont" line 3)
invoked from within
"setfont .$module $module_font"
("foreach" body line 1)
invoked from within
"foreach module $module_list {setfont .$module $module_font} "
invoked from within
".main_menu.mb9.m.m2 invoke active"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke active]"
(procedure "tk::MenuInvoke" line 47)
invoked from within
"tk::MenuInvoke .main_menu.mb9.m.m2 1"
(command bound to event)Maciek
______________________________
Michael Barton, Professor of Anthropology
School of Human Diversity and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton