I have multi-monitor setup with one monitor in landscape orientation, other one in "portrait", as on left part of this diagram:
| | | |
| | | 3 |
| | | |
+---------| B | +---------| . . . |
| | | | | |
| A | | | 1 | 2 |
| | | | | |
Now windows placed in area 1 or 2 can be resized normally. But if a window is placed in area 3, once I try to resize it vertically in such manner that bottom border would be affected, the bottom border immediately will always immediately snap to imaginary line between 2 and 3.
The snapping happens always, no matter how close the border actually is, so it's impossible to resize the window normally. (It's still possible to work around this by resizing it using top corners/border and moving it, or by moving it elsewhere, resizing and moving back).
With above layout, I haven't seen the problem affecting top, left or right borders, as one could expect. Also it does not affect window that is partially in area 2 and partially 3.
Created attachment 5521
resizing Orage window - before
Created attachment 5522
resizing Orage window - after
Created attachment 5523
Created attachment 5524
Note to screenshots:
The presence of the Mousepad window on screens is only to demonstrate where exactly the bordwe is landing (i.e. it's not exactly at level of top of the monitor A, or at level where A's panel ends). It does not affect the behavior; if the Mousepad window is removed, the Orage window would snap to the same place.
Also, the system where I see the problem is Fedora 20:
I can confirm and I'm experiencing same bug on xfwm4 4.10.1.
I posted a $50 bounty for this: https://www.bountysource.com/issues/3235334-multi-monitor-cannot-resize-window-properly-due-to-snapping, fix this bug and receive $50.
I use dual screen setup as seen below:
| resize ok |
|- B -|
| snaps |
| xfce panel |
| A |
| xfce dock |
Screen B is where I experience this bug, resizing windows in the bottom half of B by using bottom border of a window always snaps windows to the bottom of B.
I use xfce daily on a wiped work macbook (not a big fan of apple).
My monitor layout is like this (note the vertical overlap):
| B |
| | xfce panel |
| A |
I get this snapping while resizing windows on B, but only if I have a panel at the top of A AND it is set to reserve space on the borders. The effect disappears if I move the panel to the bottom of A or if I check "don't reserve space".
When the snapping occurs, it is to the line through the lower edge of the panel. The bug seems to be in the way space is reserved for the panel (also desktop icons are squeezed into the gap between this line and bottom of B).
(debian/testing + xfce from git master)
Created attachment 5844
patch to fix wrong snapping on window resize
Attached is a patch which fixes this bug for me.
The bug lies in the way the resized window is checked for valid position: the current code doesn't support partial struts. It turns out that the function for performing this check on moving a window can also be used here, so the patch is very simple. Using the same code for both checks ought to make maintenance easier in the future.
The diff is against the latest release version 4.11.2, but has been tested with the latest code from git.
One note on the patched version: on resizing a window in such a way that part of it lies in a zone forbidden by struts, the window will be moved so that it is in a legitimate part of the screen. At first, this behaviour seems strange and I spent a long time trying to work out how to stop this. But eventually I concluded this is correct, on the principle that, unless impossible or dangerous, direct user requests should be accommodated. (Example, in the layout in my previous comment, dragging the bottom-right corner of a window on the left monitor onto the right monitor can put that window's top-right corner into the space above the panel on the right monitor. In this case the entire window is moved below the level of the panel.)
contrainPos can't be used in this context, it moves the window but does not change the size.
Actually, we can use constrainPos(), just need to record the position before and compare to the position after and resize accordingly.
Should be fixed with commit b97b148, thanks for the idea.