GNOME Bugzilla – Bug 126792
Better window placement
Last modified: 2008-06-13 18:00:41 UTC
Hi, I'm openning this bug for a discussion on better window placement in metacity. To shortly describe the current algorithm, it tries to put the window on a black area on left or below of a window, and if it fails, simply cascades them from the corner. The current algorithm does well when there are almost no windows on the desktop, but when you have a bunch of them open, and working with a few of them, it fails to open windows on the right place. I like it when I login and open a terminal and duplicate that and it goes below the first one, not over it, but it's just when you login and there's no window open. The current algorithm can be improved in two ways: * Generate more candidates. Currently they are so limited that it usually leaves some empty space, just because no window behind or to the right of an existing one (aligned to the left/top of the old one) can fit there. * Do not simply fail if we cannot find an empty space. Find a suitable place anyway. Another strategy is to remove the current algorithm, and design a new one. I would discuss it later.
Let's see what do we like as a good placement: * If there is an empty space that window fits, we like to get it there. * If there's not, better we put the window on top of not-recently-used windows. For the least it never should show over the focused window (most-recently-used then). * Sometimes we prefer locality, means, want the new window, as near as the currently focused one as possible. You can findout what do I mean by these items, and how they should mix somehow magiacally...
Created attachment 21375 [details] [review] First window placement patch. Agains CVS
Just attached the first patch agains CVS. Beside general cleanup, I have advanced place.c, so that: * Traverses the relevant windows (not minimized, on the same display, screen, ...) in the mru (most recently used) order, and test below, right of, above, and left of them for the best suitable place. * Best suitable place is the one which does not overlap as much recently used windows as possible. * If no suitable place is found, in the sense that all proposed places would overlap with the top-most window, it would fall back to the old cascade mechanism. Give it a try, with a large desktop as mine (1600x1200), and a few applications open, and yourself hacking in a terminal which is smaller than 800x600, you would love it how opening a new terminal would not overlap your current one. Would do more later. Comments welcome.
To test it: Checkout metacity from CVS, apply patch, build. run metacity/src/metacity --replace.
It has promise but there's a number of problems with this implementation that would need to be addressed in the final version: first, it does not handle the xinerama case well at all. Second, it loses a lot of "predictability," i.e. windows seem to sort of pop up randomly. Finally, it would need some way to prevent placing right on top of existing windows, as it seems to do now, which you can see just by opening several terminal windows with a hotkey (this we could perhaps deal with by generating a cascade at that point when this happens, or by adding some sort of timestamp to the windows so we could assess "how long ago" the window was last focused). And, of course, in sloppy or mouse focus mode this just becomes insane. That said, I have been meaning to try to come up with a way to deal with the "upper left corner syndrome" of metacity, where it usually ends up putting a window into the upper left corner of the current xinerama when it can't figure out a place to put it. Trying the left and top of existing windows is one thing I was going to try when I got around to it (but it would need to try bottom, then right, then top, then left). The other thing I wanted to try was to move the cascade out of the upper left corner so that the window will be placed further down and to the right. But we do need to make sure that the xinerama placement remains robust and that we don't place windows exactly overlapping other windows.
The problem with the upper left corner syndrome is that it forces the user to move the window out of there 99% of the times. I think the top of the screen is never a good place to place a window, it is even worse than popping a window partially overlapping the window that the user is currently working on, as this last scenario only requires the user one click and not a click-and-drag.
I've got some free time to work on it again. I will try to summarize the suggestions in a patch and see what happens. This weekend probably...
updating per comments
actually I'm just going to close this bug for now, since its not actually a bug. Please feel free to reopen if you work on this again.