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.
fredh@hpcvlx.cv.hp.com (Fred Handloser) (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. > I don't want to call you a lunatic, but ..., :-) >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. Mwm 1.1 does this now. > >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. I hope the rest of the world agrees with you since this is the current behavior of mwm 1.1 . > >Thank you for your support. > >-- >Kaleb Keithley Jet Propulsion Labs >kaleb@thyme.jpl.nasa.gov > >Stirring up trouble again. >---------- I responded to a similar note in notif.talk. Here is my response from there. Mwm 1.1 will use the current screen for an f.exec'd action unless the f.exec command explicitly sets the display. Check your f.exec line to make sure you are not setting the display to screen 0. You really do not need multiple root menus. Fred Handloser Interface Technology Operation Hewlett Packard Corvallis, OR.
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.