GNOME Bugzilla – Bug 143784
Initial spatial window placement is Xinerama ignorant.
Last modified: 2008-06-19 12:24:03 UTC
This bug has been reported in the Debian BTS: http://bugs.debian.org/249921 "1) Create a new folder on your Destop. 2) Open the new folder. 3) Be annoyed as the window is placed in the center of your multi-monitor configuration. The spatial Nautilus seems to be overriding GTK+'s support for Xinerama. It appears to be taking the total desktop size and placing the window in that center rather than just calculating for a particular head."
Related issue: I understand one of the features of spacial nautilus is that it remembers where a folder was when it was last closed. Apparently, this memory spans the Xinerama displays, so if you last closed a folder on the right side, it will reopen on the right side, even if the "parent" window is on the left side. This is quite counterintuitive and means you need to keep looking back and forth between displays and dragging folders back where they belong. If nautilus is going to remember the last state of your window, it should be with respect to the active Xinerama display, not the entire (double-width) desktop.
*** Bug 309101 has been marked as a duplicate of this bug. ***
Setting versions.
*** Bug 170154 has been marked as a duplicate of this bug. ***
Without looking at the code, it would seem the reason for this is that windows and dialog boxes (such as the open location dialog) are being parented on the window that is the Nautilus desktop (which spans both screens) and centred on that parent. I'm going to tentatively mark this as a GNOME 2.12 bug, as this is a highly user visible bug that will annoy the industry movers and shakers who we want to write good reviews about us.
Created attachment 49628 [details] [review] make Ctrl-L dialog Xinerama aware This is the first patch of what could end up a number like it. It checks to see if the window is in fact the desktop window, and then repositions the dialog to not be centred on the parent (ie, spanning screens). The dialog is centred on the window which currently has the mouse on it. It might pay to have this calculation split out into a generic utility function. This has not currently been tested on a single monitor machine, but could be activated with use of the call gdk_screen_get_n_monitors() if required.
The delete confirmation dialog also suffers from this problem, so it's probably a good idea to split this out into a utility function.
Elijah suggests fixing this placement in Metacity. For what it's worth, Sawfish seems to be doing something like that. The question is how do we handle dialogs centred over parents in a more general case, do we centre them over the part of the window on one monitor?
Created attachment 49662 [details] [review] two dialogs Move the recentring code into a utility function. Make location dialog, and delete confirmation recentre on the focused monitor.
Since nautilus isn't setting any window position here i think this should be fixed in metacity. After all, metacity is what decides to center the dialog over the parent. If this e.g. changes in the future, then the hardcoded fix in nautilus would be wrong. Metacity could either special-case _NET_WM_WINDOW_TYPE_DESKTOP, or just in general handle window placement of child windows where the parent occupies several xinerama screens better.
I don't think this is a release showstopper (it's annoying, but that's about it), so I'm dropping the Gnome 2.12 milestone. For those that have a xinerama setup to test with and would like to tackle this bug, look for "/* Center horizontally, at top of parent vertically */" in meta_window_place() (which is in metacity/src/place.c)
[Cue Wizard of Oz music] Ding! Dong! The bug is dead! The wicked bug, The wicked bug, Ding! Dong! The wicked bug is dead...