Xref: utzoo comp.windows.x:27635 comp.windows.x.motif:828
Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!thyme!kaleb
From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley	)
Newsgroups: comp.windows.x,comp.windows.x.motif
Subject: Poll: How should mwm -multiscreen work?
Message-ID: <1990Oct1.174410.24030@thyme.jpl.nasa.gov>
Date: 1 Oct 90 17:44:10 GMT
Sender: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley	)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 34

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.

I believe this to be a major failing.  An email conversation with David
Brooks of OSF has identified two options:

1.  Using resources, create separate, nearly identical root menus in 
my .mwmrc which set an appropriate -display command line option for 
the f.exec on each screen.

2.  OSF can modify mwm to explicitly set the "envariable" to match the
screen on which the action is taken.

I personally opt for the latter.  What does the rest of the world think?
Email me, I will summarize and submit/not submit a bug report based on
the outcome of the poll.

Thank you for your support.

-- 
Kaleb Keithley                      Jet Propulsion Labs
kaleb@thyme.jpl.nasa.gov

Stirring up trouble again.