[GRASS5] d.m and d.mon fail after cvs update

[Michael Barton]

Glynn,

Currently when I use monitor override, I cannot open an xmon window from the
GIS Manager. I get a 'No socket to connect to for monitor <x0>' error.

The way I had it was ...

d.mon start=gism -s
set env(MONITOR_OVERRIDE) "gism"
...display commands
d.mon stop=gism

If I try to start an xmon (e.g., for v.digit), I get the 'No socket...'
error.

If I change to...

d.mon start=gism
...display commands
d.mon stop=gism

I get no error.

I've tried using monitor override to select the xmon for v.digit (or other
module that needs it) and unsetting monitor override after stopping gism.

This is not a big issue now. But when I start redoing the compositing, I'll
want to keep gism running all the time, except when doing a window resize.
Then I'll really need to use monitor override.

Any ideas?

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution 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


> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Thu, 23 Feb 2006 14:59:19 +0000
> To: Michael Barton <michael.barton at asu.edu>
> Cc: "Kirk R. Wythers" <kwythers at umn.edu>, devel grass <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] d.m and d.mon fail after cvs update
> 
> 
> Michael Barton wrote:
> 
>> I had this problem, but fixed it in a different way and so need to ask about
>> it.
>> 
>> I had a strange monitorcap (with double xmon definitions) file that came
>> with the most recent (13 February) Mac binary from Lorenzo Moretti. Perhaps
>> this is/was being generated during Mac compiles as this seems to be reported
>> by Mac folks.
>> 
>> When I fixed the monitorcap file AND commented out the following line...
>> 
>>                 #set env(MONITOR_OVERRIDE) "gism"
>> 
>> in the procedure that creates the output PPM and then creates a TclTk image
>> from thePPM, it worked.
>> 
>> With the fix you mention below, should I try uncommenting the
>> MONITOR_OVERRIDE statement?
> 
> The use of MONITOR_OVERRIDE and the fix which I mentioned are
> unrelated.
> 
> Without the version.h.in fix, monitor drivers will simply segfault at
> startup. the fix is necessary to be able to use monitors.
> 
> MONITOR_OVERRIDE allows applications to redirect d.* commands to a
> specific monitor without using "d.mon select=..." (which will
> interfere with the user's use of monitors).
> 
> gis.m should always be using MONITOR_OVERRIDE rather than
> "d.mon select=gism".
> 
> BTW, It is now be possible for gis.m (and similar programs, e.g.
> d.out.png) to avoid the use of monitorcap altogether. You can start
> monitors directly with e.g. (shell syntax):
> 
> $GISBASE/driver/PNG foo '' ''
> MONITOR_OVERRIDE=foo d.vect fields
> d.mon stop=foo
> # or:
> # $GISBASE/etc/mon.stop foo
> 
> without the monitor name having to appear in the monitorcap file.
> 
> This doesn't work when using FIFOs, although I don't know if anyone
> still uses FIFOs, and I'm inclined to remove FIFO support altogether
> unless someone can provide a good reason why it needs to stay.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>