[GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows, nviz

[Helena Mitasova]

On Thu, 2007-08-23 at 23:15 -0700, Michael Barton wrote:
> I've gone through and wrapped in catch statements all GRASS commands worth
> wrapping (and probably some not worth it).
> 
> I also did a bit of cleanup to the help routines that I ran across.
> 
> I also added Carlos' get info buttons to the raster and vector layer panels.
> These are quite handy.
> 
> There is a bug in v.what such that it kicks out the wrong stuff with its GUI
> interface description. Only shows up from the GUI, but it would be nice if
> it could be fixed.
> 
> Anything else GUI-wise broken and fixable that anyone has noticed?

There still seems to be a nviz GUI redesign related problem 
(it may be due to my set up, but Paul said
that he has a problem with Save state on his freshly checked GRASS CVS
too.)

I have compared nviz in 6.2.1 that had older interface and Save State
works there (at least to some extent) with 6.3 and the state
files are indeed different - in 6.3 the light data are missing and the
order of saved settings is different (the later may not matter).
But the real problem is that nviz in 6.3
cannot read the saved settings and I get the following error:

Diagnostic: wrong # args: should be "set varName ?newValue?" --  Load
procedure for panel main may not be defined
Diagnostic: invalid command name "Nviz_720 752_load" --  Load procedure
for panel 720 752 may not be defined
Diagnostic: invalid command name "Nviz_22.0_load" --  Load procedure for
panel 22.0 may not be defined
Diagnostic: invalid command name "Nviz_4.462_load" --  Load procedure
for panel 4.462 may not be defined
Diagnostic: invalid command name "Nviz_379.50_load" --  Load procedure
for panel 379.50 may not be defined
Diagnostic: invalid command name "Nviz_0.504 0.984_load" --  Load
procedure for panel 0.504 0.984 may not be defined
Diagnostic: invalid command name "Nviz_1_load" --  Load procedure for
panel 1 may not be defined
Diagnostic: invalid command name "Nviz_234.500000 234.500000
120.363991_load" --  Load procedure for panel 234.500000 234.500000
120.363991 may not be defined

There is also a problem with scripts - I don't think it is directly in
the file sequencing tool as I assume that it has not been touched, but
some of the recent changes must have affected handling of map names:

section of nviz script created by file sequencing tool

old that worked:

 if {$iloop4 < 8} then {
  if {[lsearch {} $iloop4] == -1} then {
   if {[lsearch {} $iloop4] > -1}  then {
    SendScriptLine "lappend NVIZ_BLANK_MAPS [ExtractMapID $mhandle6]"
   } else {
    SendScriptLine "$mhandle6 set_att color [lindex {hfl.sig100 at indyfi
hfl.sig10 at indyfi hfl.sig1 at indyfi hfl.sig05 at indyfi hfl.sig03 at indyfi
hfl.sig01 at indyfi hfl.sig005 at indyfi hfl.sig001 at indyfi} $iloop4]"
   }

new that does not work for obvious reasons (full path instead of
rastername at mapset) :

 if {$iloop3 < 1} then {
  if {[lsearch {} $iloop3] == -1} then {
   if {[lsearch {} $iloop3] > -1}  then {
    SendScriptLine "lappend NVIZ_BLANK_MAPS [ExtractMapID $mhandle4]"
   } else {
    SendScriptLine "$mhandle4 set_att topo [lindex
{/local/home/helena/grassdata07/nc_spm_05/user1/cell/elev_lidtopandef_1m at user1} $iloop3]"

The reason for the above problem seems to be that the save fields
function saves full path instead of name at mapset

/local/home/helena/limg/grassbook/dynsurf.state.nviz
2
Surface
Topography
surf*1185562518
1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/elev_lidtopandef_1m at user1
Surface
Color
surf*1185562518
5
/local/home/helena/grassdata07/nc_spm_05/user1/cell/distr_2m.0418 at user1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/distr_2m.0438 at user1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/distr_2m.0458 at user1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/distr_2m.0478 at user1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/distr_2m.0498 at user1

the old field file has just
distr_2m.0418 at user1
distr_2m.0438 at user1

I am hoping that the fix is not too complex,

Helena
> 
> Michael
> 
> 
> On 8/22/07 4:22 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:
> 
> >>> A couple of side-notes though:
> >>> 1) In general the GUI is terrible at catching and reporting errors from
> >>> modules it calls in the background and this leads to cryptic error
> >>> messages or nothing happening all over the place. IMHO it is a really
> >>> pervasive problem that definitely needs fixed in the next GUI. Hopefully
> >>> it already is there (ISTR discussions about every call to a GRASS module
> >>> going through some other function where the error trapping could
> >>> presumably be added, to avoid code repetition).
> >> 
> >> Actually, error trapping is pretty good in the GUI now, except for NVIZ (but
> >> which doesn't run much in the way of GRASS commands anyway). There are traps
> > 
> > Well maybe I was being a bit overly dramatic, but running
> >   grep "exec " *.tcl | grep -v catch | wc -l
> > in the gis.m directory still reveals 72 lines where exec is used without a
> > corresponding catch. Not very scientific and perhaps not important in most
> > cases - but if a single command (be it a GRASS module or system command)
> > is not available or not working for some reason it could really make the
> > difference between somebody tearing their hair out for a day or finding
> > the source of a problem quickly.
> > 
> 
> __________________________________________
> 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
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev