Bug 4066 - Incorrect menu and popup placement in qt4 applications with Xinerama
Status: CLOSED FIXED
Alias: None
Product: Openbox
Classification: Unclassified
Component: general
Version: 3.4.8-rc1
Hardware: PC Linux
: P3 normal
Assignee: Dana Jansens
QA Contact:
URL:
: 4444
Depends on:
Blocks: 3888
 
Reported: 2009-05-12 18:54 EDT by Jim Paris
Modified: 2010-01-04 11:40:04 EST
2 users (show)

See Also:


Attachments
Correct menu placement, when parent is on the primary Xinerama screen (35.96 KB, image/png)
2009-05-12 18:56 EDT, Jim Paris
Bad menu placement, when parent is on the secondary Xinerama screen (30.12 KB, image/png)
2009-05-12 18:56 EDT, Jim Paris

Description Jim Paris 2009-05-12 18:54:40 EDT
Hi,

There seems to be a bug regarding popup and menu placement with qt4 applications and Xinerama -- all popups appear on the primary display.  You can recreate this with:

# Make a fake display
Xnest :1 -ac -geometry 1024x768+0+0 &

# Load openbox with simulated xinerama
DISPLAY=:1 ./openbox/openbox --debug-xinerama &

# Load an application that exhibits the problem (qtconfig-qt4 4.4.3-1)
DISPLAY=:1 qtconfig-qt4

When the qtconfig window is in the left half of the screen, menus work fine (see attached: good.png).  When the qtconfig window is in the right half of the screen, menus appear in the wrong spot (see attached: bad.png).
Comment 1 Jim Paris 2009-05-12 18:56:01 EDT
Created attachment 2063 [details]
Correct menu placement, when parent is on the primary Xinerama screen
Comment 2 Jim Paris 2009-05-12 18:56:50 EDT
Created attachment 2064 [details]
Bad menu placement, when parent is on the secondary Xinerama screen
Comment 3 Dana Jansens 2009-12-14 15:44:33 EST
Qt menu positions are controlled by Qt itself.  Openbox is not really involved.  I'd like to know if this still occurs, and if it does, does it happen in any other window manager (or when youre not running one at all?).

Qt menus are working okay in Xinerama for me regardless, so I'm going to mark this resolved unless I hear otherwise.
Comment 4 Jim Paris 2009-12-14 18:21:31 EST
The above test case still shows the problem for me.  But it's a bit hard to track down.  The real test case that I have for this problem is using the Cadsoft Eagle layout editor (closed source, free download at http://www.cadsoftusa.com/download.htm).  The problems started when they switched to qt4 in their binaries.

1) Real X with xinerama + openbox + eagle 5.6: Broken
2) Real X with xinerama + metacity + eagle 5.6: Fine
3) Real X with xinerama + openbox + qtconfig-qt4: Fine
4) Xnest + openbox --debug-xinerama + qtconfig-qt4: Broken

I was hoping that if we can fix the cause of the bug when running inside Xnest, then maybe the Eagle bug would go away as well.

Currently my workaround is to switch to Metacity whenever I use Eagle.
Comment 5 Dana Jansens 2009-12-16 09:59:00 EST
I was able to reproduce the problem with --debug-xinerama and Xephyr.  This behaviour is fixed by commit 3c688bc4a75436a457d3ce693eda6bd6b329412f.  (Good catch on the bug relationship, mikachu.)  So it will be fixed in the next release.  Thanks for your input!
Comment 6 Jim Paris 2009-12-16 14:02:46 EST
I don't see 3c688bc4a75436a457d3ce693eda6bd6b329412f, could you push it so I can give it a try?
Comment 7 Mikachu 2009-12-16 14:22:59 EST
Make sure you're using dana's git tree, and not mine, as I'm not currently tracking it super actively.
Comment 8 Jim Paris 2009-12-16 14:54:59 EST
Cool, didn't realize he had a separate tree.  I just tested dana/3.4-working and everything looks fine now.  Thanks Dana!
Comment 9 Dana Jansens 2009-12-16 15:44:25 EST
cool thanks for testing
Comment 10 Dana Jansens 2010-01-04 11:40:04 EST
*** Bug 4444 has been marked as a duplicate of this bug. ***