GNOME Bugzilla – Bug 108152
new constraints code doesn't use xinerama work areas correctly
Last modified: 2004-12-22 21:47:04 UTC
The constraints code isn't quite right for dealing with workareas that have potentially different sizes. The attached patch has no effect on any behavior of current metacity (though I changed the order of some of the calls resulting in one fewer traversals through the xinerama list), but when work_areas actually have potentially different sizes this patch will cause the constraints code to work correctly.
Created attachment 14955 [details] [review] deal with per-xinerama work areas
aren't the nw_x etc. also used for the onscreen constraint, so this would keep you from moving windows between xineramas?
I admit it seems like that, but by the time you get the window to the point where the onscreen constraint would be a problem, the xinerama of the window has changed. If your window is really small this can be a problem, but once we fix Bug 94815 that problem will be fixed as well. Basically we need to ensure that the onscreen constraint threshold is always less than half the size of the window.
Although now that I think about it this could be a problem for xineramas arranged vertically, since we don't allow any part of the titlebar to go offscreen. Perhaps we need to look at both work areas and use the one always which is least restrictive. That seems like it would work in all cases.
Some testing reveals that using the least restrictive of the two is the correct solution. Since the all_xineramas work area will include struts from any workarea, it is always at least as restrictive in terms of struts, but is not as restrictive in terms of xinerama borders. I'm attaching an updated patch.
Created attachment 14958 [details] [review] updated patch
This is also fixed in my partial-width struts patch.
now fixed in CVS