[GRASS-dev] GRASS 6.3.0 release preparation

[Michael Barton]

Massimo,

Thanks for reporting this. I've been following up on your report and found
very puzzling behavior, and finally identified the cause. I'll explain it
and offer a couple ideas for a solution.

The d.nviz button is a legacy of d.m because it allows you to interactively
create a fly-though path by drawing with a mouse in an xterm display
monitor. d.nviz then uses the result to create the path for NVIZ.

In order to make it work with the new display system in the current GUI, the
button first attempts to launch an xterm display monitor, using a TclTk
procedure "guarantee_xmon". This procedure runs d.mon -L to see what display
monitors are available and launches the first available one. It uses an xmon
that is not currently running to avoid overwriting anything that you may be
using an active xterm display monitor for.  Although something of a kludge,
the procedure works OK for the few commands that need it (e.g. r.digit)
EXCEPT the d.nviz button.

When the d.nviz button is pressed, a bit of debug code showed that ALL
monitors were running and none were available to use for drawing a flight
path. This is what is causing the error. The puzzling part is why ALL
monitors should be running for the d.nviz button when NO xterm display
monitors are running for any other command that needs an xterm.

It turns out that an environmental variable "GRASS_RENDER_IMMEDIATE", which
needs to be set to TRUE at the beginning of a TclTk GUI session for the
display environment to work most efficiently, sets all xmons to running.
This makes it impossible to open an unused xterm monitor for any command
launched from the toolbar.

So what to do...

1. Remove the nviz button and d.nviz buttons from the toolbar and put them
back into the menu somewhere. There is no obvious place to put them (since
nviz will display both rasters and vectors), but I guess the file menu would
be OK. This should probably be done anyway to make sure a generic version of
each command is available somewhere. It would be up to the user to launch an
xmon and display a map in it for interactive fly-through creation. But the
command would work.

2. Probably the best solution would be to put the d.nviz button into the
mapdisplay toolbar and write a TclTk wrapper for d.nviz. This would let you
draw the path on the map display canvas, grab the xy coordinates of each
node, and send them to d.nviz for path creation. I don't know how difficult
this would be to do. I'll look into it and report back. I also don't have a
feel for how widely used this function is to justify the efforts for custom
interface design. I'd appreciate any feedback on this.

Michael


On 8/11/07 4:58 PM, "massimo di stefano" <massimodisasha at yahoo.it> wrote:

> Hi,
> 
> i'm using 6.3-cvs on osx 
> i compile it every 2-3 day on osx
> i found a problem running d.nviz from the gis.m button (fly trhough path for
> NVIZ)
> when press the related button i've this log :
> 
> can't read "xmonlist": no such variable
> can't read "xmonlist": no such variable
>     while executing
> "lindex $xmonlist 0"
>     (procedure "guarantee_xmon" line 16)
>     invoked from within
> "guarantee_xmon"
>     (procedure "Gm::fly" line 3)
>     invoked from within
> "Gm::fly"
>     ("uplevel" body line 1)
>     invoked from within
> "uplevel \#0 $cmd"
>     (procedure "Button::_release" line 18)
>     invoked from within
> "Button::_release .mainframe.topf.tb1.bbox4.b1"
>     (command bound to event)
> 
> runnig d.nviz directly from command line everyting works fine.
> 
> to check if it is related to my ststem configuration 
> i've compiled grass 6.2 using the same dependancie that i use for 6.3 release
> and i've that in grass-6.2
> d.nviz works fine using the gis.m button
> 
> 
> 
> nice to see that a7.0 is coming :-)
> 
> really thanks to all developpers!!!
> 
> Massimo Di Stefano
> 
> 
> Il giorno 11/ago/07, alle ore 23:05, Helena Mitasova ha scritto:
> 
>> 
>> On Aug 11, 2007, at 4:14 AM, Markus Neteler wrote:
>>  
>> 
>> 
>>  
>>> Hi,
>>>  
>>> 
>>> 
>>>  
>>> 
>>> I think that it is time to get out a GRASS 6.3.0 release
>>>  
>>> 
>>> (as sort of technology preview). It would be great to
>>>  
>>> 
>>> have it ready for FOSS4G2007, say, September.
>>>  
>>> 
>>> 
>>>  
>>> 
>>> IMHO, GRASS 6.3-CVS is in a good shape. Thoughts?
>>>  
>> 
>>  
>> 
>> Before the release, can somebody please double check that the following works
>>  
>> 
>> (most of this I believe was already discussed and should be fixed):
>>  
>> 
>> 
>>  
>> 
>> - nviz: you can add additional surfaces using the Raster surfaces panel
>> without crashing nviz
>>  
>> 
>>   (please try different resolutions, spatial extent, mapsets)
>>  
>> 
>> - nviz: mask the displayed surface using a selected raster map from within
>> nviz (in my version the
>>  
>> 
>> mask only masked the displayed vector data)
>>  
>> 
>> - nviz: save state - you can save the state and then load it and you can
>> start working where you
>>  
>> 
>>   stoped when you saved your state
>>  
>> 
>> - nviz: when saving the image, that the actual displayed image is saved
>> rather than redrawn image
>>  
>> 
>> (for example if you have loaded 4 surfaces and you display only one of them
>> the automatic redraw
>>  
>> 
>>   during the saving procedure would display all four)
>>  
>> 
>> - nviz: file sequencing tool saves the entire path rather than just the name
>> of raster maps which
>>  
>> 
>>   nviz then cannot interpret when you try to play the script
>>  
>> 
>> 
>>  
>> 
>> I hope that most of this has been already fixed but generally I have a 4
>> months old nviz on Mac
>>  
>> 
>> having more capabilities fully functional than my few weeks old version on
>> RedHat Linux,
>>  
>> 
>> so it would be good to test before releasing.
>>  
>> 
>> 
>>  
>> 
>> Otherwise GRASS63 is probably in better shape and more systematically tested
>> than any
>>  
>> 
>> previous release as both Markus and I ran almost all GRASS commands (not with
>> all options though)
>>  
>> 
>> and although there has been some level of frustration, most things work very
>> well.
>>  
>> 
>> 
>>  
>> 
>> If you ask me what was the most annoying (but not critica) thing that I have
>> found when using
>>  
>> 
>> GRASS under a deadline - then it was the large default size of the centroid
>> symbol in d.vect.
>>  
>> 
>>  I had to go through large number of vector data when preparing the new data
>> set
>>  
>> 
>> and each time I forgot to set the size smaller I got the unreadable mess of
>> overlapping crosses.
>>  
>> 
>> So if we could change the default to something smaller - perhaps size 2
>> rather than 5,
>>  
>> 
>> that would be great, because most of the time you really want to see your
>> polygons
>>  
>> 
>> not the centroids and they are quite visible at size 2 even with my old eyes
>>  
>> 
>> (maybe make the default red as the default fill is grey). This was already
>>  
>> 
>> discussed some time ago too.
>>  
>> 
>> 
>>  
>> 
>> Helena
>>  
>> 
>> 
>>  
>> 
>> 
>>  
>> 
>> 
>>  
>>> 
>>>  
>>> 
>>> Markus
>>>  
> 
> 


__________________________________________
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20070812/2d994f48/attachment.html