GNOME Bugzilla – Bug 105133
With a 3-monitor xinerama, window placement bad
Last modified: 2005-08-17 14:27:22 UTC
With one or two monitors, I can understand how the default window placement is reasonable. However, with a 3-monitor, side-by-side xinerama, the usability of metacity degraded by the default window placement. New windows always appear on the left-hand side of the left monitor. Just about anyone who has 3 monitors side-by-side will seat themselves directly in front of with the middle monitor and be flanked by a monitor to both the right and left. This suggests, in particular, that new windows should always appear by default in the center monitor when there are 3 monitors side-by-side. In general, it may be reasonable to assert that new windows should always appear in the center monitor whenever there are an odd number of monitors side-by-side.
Perhaps placement should always be on the "current" monitor (containing the mouse pointer)
Agreed. At first glance, I like that even better than my original suggestion.
I'm not sure about the idea of always trying to place on the xinerama with the pointer. I considered this when I wrote the xinerama placement code, but rejected it since I wanted to be able to use both xineramas on my system even though I might launch applications only from the gnome menu on my left monitor. I wanted the placement algorithm to use all the space available to it without piling everything onto one xinerama. Although the three-monitors side-by-side thing does present an interesting issue that ought to be fixed. I think we might be able to come up with a reasonable heuristic as to the order in which we try placing windows on xineramas. Perhaps we could start from the "centermost" xinerama and sort of move "outward" from there, placing windows until full in the middle, then left, then right, then for people with really insane setups up, then down. This would be relatively easy to implement, as the order corresponds to a particular breadth-first visitation of the "xinerama graph", but I think we should wait until the saving window positions and per-xinerama work_areas patches are dealt with. (Bugs 95014 and 91481). Comments? -Rob
I'm working on a patch to implement roughly the algorithm that I described above, i.e. doing a breadth-first search of xineramas outward from the xinerama with the pointer. This one will be a bit tough to test though since my setup has only two heads, so if the submitter or somebody with some large number of heads is willing to hammer on this a bit that would be great (using three heads set into strange and unusual configurations would be good). The patch I'm attaching rewrite find_first_fit, making it easier to understand, and taking advantage of a new function in screen.[ch] meta_screen_get_natural_xinerama_list, which returns a list of xinerams in the "natural" ordering explained above. It goes through this ordering to find an xinerama on which to point windows. Note that if people like this idea, I also want to place new maximized windows using this ordering (see Bug 105270), but first things first, no?
Created attachment 14626 [details] [review] xinerama placement enhancement patch
marking PATCH/high, since I forgot to do so before
This patch turned out to be kind of hard to read because of the way diff decided to do the patch. If you want to be able to understand what is going on in find_first_fit, you should just apply the the patch, and all will become clear.
I would really like to have the opportunity to open all apps on one screen (and I would like to select which screen that is), so I can just drag them where I want them. Is that possible in a future version?
among other things, this patch does that. If there's room on the screen with the pointer, it puts the window there. -Rob
Ok.. I would like to have the option to open the apps there even when there is no room for it. But beggars can't be choosers, I guess :)
Btw. I want this for several reasons. For example when using OpenOffice.org Writer, and I open the settings dialog, I really don't want that on my other display. That's just silly, isn't it? Speaking of OpenOffice.org... When I launch OOo Writer, the splash screen is on both screens, but I guess that could be another bug. Thanks.
I'd consider both of those OO.o bugs - the settings dialog should have its transient parent set to the OO.o main window, and if it is, metacity should and I'm pretty sure does center it over the main window. Metacity could be slightly smarter here, and when centering a parentless dialog onscreen, center over the xinerama containing most of the app instead of on the current xinerama. That might be a good improvement. The splash screen issue is definitely OO.o - that window is currently override redirect, so metacity doesn't even see it. If it were non-override redirect and had the type SPLASH set, then metacity would handle it properly.
do you know when/if you'll get a chance to look at this patch, Havoc? It's pretty well-tested and I think fairly solid, but it also has a failsafe fallback to something like the old behavior if the xinerama traversal fails. -Rob
The basic idea of the patch looks good to me. The only nitpick I'd have is that I think we should prefer the xinerama containing the pointer (or even better, the one where startup notification says the launch occurred, falling back to the one with the pointer if that fails). However, if the one containing the pointer/launch is full, then we'd place on another xinerama rather than overlapping windows. But if we can't find anywhere that doesn't overlap, again the pointer/launch xinerama would be preferred. Does that make sense? Other than that I see mostly style nitpicks: - "foo (" and "for (" not "foo(" - don't cast to void*/gpointer explicitly - (for that matter, use void* not gpointer ;-)) - use "visited[i] = TRUE" not "visited[i] = 1" Thanks, sorry to be slow (as usual)
Does startup notification give us an xinerama where the launch occured? Or just a workspace? It would be cool if we could do that. Right now if just uses the pointer position to figure out where to start from, and places preferentially on that xinerama. After that it tries to get as close to the pointer as it can without overlapping windows. We should probably also update find_next_cascade to cascade onto the xinerama with the pointer as well but first things first. Regardless I'm attaching a de-nitpicked patch. If you don't like casting to void*, you'll LOVE casting away const!
Created attachment 15503 [details] [review] fewer nits; lower in calories!
opps, I missed a "== 0" := "== FALSE". I fixed it. You'll have to trust me on that ;-)
Looks good to commit to me, thanks.
Committed. Thanks for putting up with my crackpot ideas :-) -Rob
So, what is the current (metacity-2.10.3) situation? I experience that after a "fresh" startup of X/Gnome, some xinerama-enabled applications like mozilla firefox always get placed on the second (right) screen unless I occupy some space on the 2nd screen. Is there an option to disable that kind of auto decision?! I would want all my windows to open on the 1st/primary screen (which would be the center screen on a triple head configuration with the additional screens on the left an on the right btw). TIA.