To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=109550 Issue #|109550 Summary|Spurious NET_CURRENT_DESKTOP requests generated by scr |ollwheel and dialog affect multiple screens Component|gsl Version|OOo 3.2 Platform|PC URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|code Assigned to|pl Reported by|robbat2
------- Additional comments from [email protected] Tue Feb 23 19:41:47 +0000 2010 ------- In Issue 45160, code was added to change desktop whenever a dialog was going to be brought up, with "fixme: multi screen case" blocks added for the WMAdaptor::switchToWorkArea and WMAdaptor::getCurrentWorkArea functions. I can't see how the triggering is happening, but whenever I use my scrollwheel in any OO application, I get NET_CURRENT_DESKTOP Xevents generated. On a single-screen system they wouldn't be a problem, as the desktop is already set, but in a multi-screen independent system, the change of desktop affects ALL screens, instead of just the one that OO is on. How to reproduce: - Start a WM that allows you to have separately changable desktops per screen (AwesomeWM in my case). - Desktops are 1-9 on each side, independent. - Place any OO application on the left screen, desktop N (any value). - Change right screen to any desktop other than N. (e.g. OO on left-9, right screen set to desktop 8) - Use scrollwheel in OO app. - OO generates a NET_CURRENT_DESKTOP change, and BOTH left and right change to desktop 9. If you had some other window in right-8 that you were trying to view while working on your OO document, it gets really annoying. As a workaround, if you only have one window/desktop you are viewing for reference, you can set them to the same desktop, but if you want two desktops of reference material, you're out of luck, as this bug keeps occurring. Proposed fixes: 1. Short-term: Provide an option to NOT change desktops, let the WM control dialog placement. Basically just never generate the NET_CURRENT_DESKTOP event. This allows a workaround for users right now, their WM is then responsible for putting the dialog on the desktop associated with OO or where the user would like it. 2. Long-term: The ICCCM spec doesn't appear to provide a way to create a new window on a specific desktop without being on that desktop, so research how to accomplish that, and simply generate the dialog on that desktop in the first place. #2 might upset some users still I think, esp. those with less-capable WMs. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
