kaleb@thyme.jpl.nasa.gov (Kaleb Keithley ) (10/02/90)
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.
jordan@Morgan.COM (Jordan Hayes) (10/02/90)
Kaleb Keithley <kaleb@thyme.jpl.nasa.gov> writes:
I believe that mwm's -multiscreen is broken.
I agree. TWM does this, and it seems to be the best solution.
From clients/twm/menus.c ...
/*
* Build a display string using the current screen number, so that
* X programs which get fired up from a menu come up on the screen
* that they were invoked from, unless specifically overridden on
* their command line.
*/
/jordanyee@osf.org (Michael K. Yee) (10/03/90)
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
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley ) (10/03/90)
In article <YEE.90Oct2163309@chapman.osf.org> yee@osf.org (Michael K. Yee) writes: > > 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 Thank you very much. Consider the "poll" terminated. -- Kaleb Keithley Jet Propulsion Labs kaleb@thyme.jpl.nasa.gov Stirring up trouble again.