Red Hat Bugzilla – Full Text Bug Listing
|Summary:||window manager restores maximised window to wrong Xinerama head|
|Product:||[Retired] Red Hat Linux||Reporter:||Bryan O'Sullivan <bos>|
|Component:||metacity||Assignee:||Havoc Pennington <hp>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-05-25 14:59:34 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Bryan O'Sullivan 2003-05-12 12:20:16 EDT
Description of problem: Although gnome-session (at least, I *assume* it's gnome-session doing this) can remember that an application was maximised, the next time the app is opened, gnome-session does not remember which Xinerama head the app was displayed on, and always opens it maximised on the leftmost head. Version-Release number of selected component (if applicable): gnome-session-184.108.40.206-4 How reproducible: 100% of the time. Steps to Reproduce: 1. Run a Gnome app, such as Evolution, on a display that's using Xinerama across more than one head. 2. Move the window so that it's mostly displayed on a head other than the leftmost head. Maximise the window. It should be maximised on whatever head it's mostly displaying on. 3. Quit the app. 4. Restart it. Notice that the new window is maximised, but that it is not displaying on the same head as it was. Actual results: The window is placed on the wrong head. Expected results: The window should be placed on the same head it originally showed up on. Additional info: That's all, folks!
Comment 1 Havoc Pennington 2003-08-07 17:25:23 EDT
This is the window manager's job, though broken apps can mess things up sometimes. Assuming metacity for now.
Comment 2 Havoc Pennington 2004-05-25 14:59:34 EDT
I was confused, this isn't supposed to work at all; there's no saving of window locations at the moment, unless you explicitly save an entire session. The only saving is happening in the apps themselves, e.g. evolution. Evolution should open on the head where the mouse is located or where it was launched or whatever the fixed rule is. Anyway, there are some gnome.org bugs about this general problem but without some big-picture changes there's no specific fix for this specific problem. Currently working as designed/expected.