Xinerama: X menus w/ windows in -y area
Brought to you by:
torrey
Menu
▾
▴
#110 Xinerama: X menus w/ windows in -y area
Same setup as my last PR (dual head, smaller screen bottom left)
Display mode: Rootless Quartz
Screen 0 added: 1280x1003 @ (0,21)
Screen 1 added: 1152x870 @ (-1152,154)
Screen 0 placed at X11 coordinate (1152,-133).
Screen 1 placed at X11 coordinate (0,0).
If I move a window up into the area at the top of screen 0 and then access a menu, instead of the menu appearing where you would expect it to, it appears at the correct x coordinate but y=0. No problems accessing the menu items (it still picks the one the mouse is over).
Eric
Logged In: YES
user_id=37183
That's definitely a window manager problem. Most
window managers don't know how to deal with
negative coordinate space. Unfortunately, they usually
don't know how to deal with (0,0) not being on any
screen, either. We enlightened Mac users with multiple
monitors at different resolutions are pretty much stuck.
(It could be worse - at one point during XDarwin
development, the menus would jump to the right
instead of down. That made them much harder to
use...)
Logged In: YES
user_id=367047
As far as I can tell this is wm independent. It may be application dependent (or X widget library dependent) but it is definitely reproducible with no windowmanager present. If I start oroborus & free the mouse & then kill oroborus (see my other xinerama bug) I'm then left with the mouse freed and no running windowmanager. xemacs -geometry +1400+-100 then opens a window up with the menus in -y, and pulling down a menu has it appear in +y territory. I'd take a screenshot but grab doesn't get X menus and xv doesn't take a picture of -y at all...
I've been working with Adrian Umpleby (OroborOSX author) on these bugs and I thought they were windowmanager-specific at first too. But they seem to be reproducable with no wm running, and not ones that can be worked around by the wm like the blank windows on the secondary display can be...
Logged In: YES
user_id=367047
Doing some work tonight in Tgif, and just realized that it *doesn't* have the menu problem. So it appears it does have to do with how the application is written and nothing in the windowmanager or X in particular. So I guess as long as we have negative coordinates we're stuck with this.
Wouldn't it be possible to have (0,0) at (-1152,21) (based on the added lines from my setup above) and then place screen0 at (1152,0) and screen1 at (0,133)? That way there are no negative coordinates... if the only problem w/ having (0,0) off screen is with the windowmanager, it would seem that just the wm needs fixing then as opposed to just about every X app out there. And Xinerama-aware wm's shouldn't have a problem at all I'd think.
Logged In: YES
user_id=37183
I'm guessing that the menu behavior is determined by the X toolkit library used by the app. Programs written with Xt might work while Motif-based programs wouldn't.
I tried putting (0,0) at the logical top left, off of all screens, but it didn't work right. I forget what exactly was wrong, but any configuration with (0,0) not at the top left of some screen didn't work.
Logged In: YES
user_id=37183
Bugs #488868 and #491920 have exposed fatal flaws in the current Xinerama implementation, so I've rewritten our multi-monitor support from scratch. A replacement XDarwin.app is at http://www.sealiesoftware.com/xdarwin-newxinerama.dmg.gz . The new code needs lots of testing if it is going to make it into XFree86 4.2; please test it if you can and file bugs if you find them.
This bug will go away as a side-effect, because the new code never places screens in negative X11 coordinate space.
In the new XDarwin's startup output, you'll see "Screen 0 added" only once, no matter how many screens you have. You should instead see one "PseudoramiX screen 0 added" for each real monitor you have.
Logged In: YES
user_id=133579
XDarwin 1.0.6 includes this fix. Please make sure this
version also works as it includes the final code (with some
small modifications) that will be part of XFree86 4.2.
Logged In: YES
user_id=367047
This bug is fixed in 1.0.6 on my system. Thanks
Logged In: YES
user_id=133579
This bug is still present in full screen mode and is now
filed under bug #496348.