Xref: utzoo comp.windows.x:27699 comp.windows.x.motif:836
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker!paperboy!yee
From: yee@osf.org (Michael K. Yee)
Newsgroups: comp.windows.x,comp.windows.x.motif
Subject: Re: Poll: How should mwm -multiscreen work?
Message-ID: <YEE.90Oct2163309@chapman.osf.org>
Date: 2 Oct 90 20:33:09 GMT
References: <1990Oct1.174410.24030@thyme.jpl.nasa.gov>
Sender: news@OSF.ORG
Organization: Open Software Foundation
Lines: 28
In-reply-to: kaleb@thyme.jpl.nasa.gov's message of 1 Oct 90 17:44:10 GMT

In article <1990Oct1.174410.24030@thyme.jpl.nasa.gov> kaleb@thyme.jpl.nasa.gov (Kaleb Keithley	) writes:
| 
| I believe that mwm's -multiscreen is broken.  Here's your chance to tell
| me I'm either right, or that I should go bark at the moon.
| 
| For starters, here's the scenario.  Running mwm 1.1 on a Sun w/ three
| frame buffers; screens 0, 1 and 2 respectively.  My .mwmrc file has an 
| entry that creates a menu on the root screen, one of which is to create 
| an xterm.  When I click on the root window of screen 0, the menu comes 
| up, I drag down to the xterm selection, release, and get my xterm on 
| screen 0.  Great so far.  Doing the same thing on screen 1 or 2 however,
| results in the xterm also coming up on screen 0.  This seems to occur
| as a byproduct of mwm's DISPLAY "envariable" (which is ":0") being
| interpreted as ":0.0" by child processes.
| 

	Yes, there is a bug in Mwm 1.1 where if the DISPLAY environment
	variable is set to ":0", f.exec's may not display on the correct
	screen.  This should be fixed by Motif 1.1.1.  But until then the
	work around is to set DISPLAY to hostname:0 (i.e. DISPLAY = unix:0,
	local:0, and hostname:0.0).  Hope this helps,

	=Mike

--
= Michael K. Yee		-- yee@osf.org or uunet!osf.org!yee --
= OSF/Motif Senior SW Engineer
= "I can't give you brains, but I can give you a diploma." -- The Wizard of OZ