Bug 321325 - Inconsistent snapping at vertical screen edges
Summary: Inconsistent snapping at vertical screen edges
Alias: None
Product: kwin
Classification: Unclassified
Component: core (show other bugs)
Version: 4.10.80
Platform: openSUSE RPMs Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/111...
Depends on:
Reported: 2013-06-18 18:38 UTC by markuss
Modified: 2013-06-26 10:58 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.11
thomas.luebking: ReviewRequest+


Note You need to log in before you can comment on or make changes to this bug.
Description markuss 2013-06-18 18:38:51 UTC
When windows snap to vertical screen edges, KWin 4.11b1 cuts off the window decoration.
Not sure if that behavior is intended or not but I find great. Nobody needs a window decoration at screen edges.

However: It's all very inconsistent.
1) Sometime the decoration is not cut off and
2) sometime the window jumps in the opposite direction.

1: Restoring windows from being minimized to tray seems the most reliable way reproduce it.
2: This is what happens when I move a window to the left screen edge: First the decoration is cut off but when I attempt to move it further to the left, the window jumps to the right, snapping to the edge with decoration visible.

Personally I find the annoyance of inconsistent behavior more grave than gaining 4 pixels.

Reproducible: Always
Comment 1 Thomas Lübking 2013-06-18 19:00:34 UTC
The behavior is intended. It's more about getting the window content (scrollbar) at the screen edge than gaining few pixels.

ad 1)
There's nothing such as "minimized to tray", the application closes the window and recreates one, often trying to restore the former position - it might be possible that the protection from off-screen mapping falsely kicks in here

ad 2)
This sounds like usual virtual desktop crossing on window drag, alongside activated quick tiling -> "kcmshell4 kwinscreenedges"
Correct assumption?

Those in a way conflict anyway.
A possible resolution is to have virtual desktops vertically stacked, ie. an equal amount of virtual desktops and rows. ("kcmshell4 desktop")
Comment 2 markuss 2013-06-18 19:08:21 UTC
1: Yeah, noticed that the coordinates are actually -4,0. Wouldn't it be better if KWin really cut off the pixels instead of simply shifting the window's position by 4 pixels?

2: I don't use virtual desktops. Number of desktops is set to 1.
Comment 3 Thomas Lübking 2013-06-18 19:19:28 UTC
Shaping the window is done by the decoration and would not change the position either. There's API support for decos to remove borders for the quick tiling condition but not general snapping.

If you've only one desktop i've no idea why the window should move to the other side of the desktop.
Do you use QuickTiling and is it related?
Comment 4 Christoph Feck 2013-06-18 22:17:51 UTC
See also bug 318107.
Comment 5 Christoph Feck 2013-06-18 22:27:42 UTC
Point "2)" can be reproduced by having two windows placed aligned above each other, one of them maximized:

| Window A - horizontally maximized |
      | Window B |

Now moving Window B to one of the left or right edges will first snap it aligned to its client. If you then move it a few pixels further, the "snap to other window" kicks in and it moves back to aligning to the decoration. Moving further, it finally unsnaps, and moves beyond the edge.
Comment 6 Thomas Lübking 2013-06-19 10:47:37 UTC
Ok, i set the BSZ to 10px and the WSZ to 5px - no CSZ; "snap windows only when overlapping" is irrelevant.

If i have a maximized window on one screen (right) and move a window on the other (left screen) towards the right edge (ie. the maximized window) that will cause the moving window to first snap the right edge content aligned to the screen and then (on moving on) snap the right edge against the left edge of the maximized window on the other screen (performing a short counter move) and then move on.

That's certainly not ideal (so i'll see how to resolve it) but i was completely unable to cause similar effects (or even have the window snap to the other side of the screen) on a singlescreen setup (or moving a client on top of the maximized client)

Window ./. Screen snapping seems to be the key nevertheless. What snap zones do you have configured? (kcmshell4 kwinoptions)
Comment 7 Christoph Feck 2013-06-19 11:10:10 UTC
> moving a client on top of the maximized client

Not "on top", i.e. not overlapping, but as in ASCII screen shot: ypos(B)=ypos(A)+height(A)
(I hate how "above" or "übereinander" doesn't allow you to state which axis you mean :)

> What snap zones do you have configured?

Border: 8, Window: 8, Center: none
Only when overlapping: off
Comment 8 Thomas Lübking 2013-06-19 11:20:04 UTC
Ah, that meakes sense (it's more or less the same condition)
And yes, describing this without mentioning the axis does not work =)

@Markus, is that what you see as well, ie. rather a little bump back and not the window snapping to the other edge of the screen?
Comment 9 markuss 2013-06-19 13:24:38 UTC
(In reply to comment #8)
> Ah, that meakes sense (it's more or less the same condition)
> And yes, describing this without mentioning the axis does not work =)
I wrote left/right, so it's obviously not the Y axis. ;-)

> @Markus, is that what you see as well, ie. rather a little bump back and not
> the window snapping to the other edge of the screen?
Yeah, that's what I meant by "jumps to the right".
Comment 10 Thomas Lübking 2013-06-19 13:27:01 UTC
The misunderstanding was between me and Christoph about Y or Z axis.
X axis been irrelevant in the first place ;-P
Comment 11 Thomas Lübking 2013-06-26 10:58:07 UTC
Git commit 736cbd016f18ea13d8da4afe3b0f7bb2ec549918 by Thomas Lübking.
Committed on 19/06/2013 at 19:28.
Pushed by luebking into branch 'master'.

exclude padding from snap delta of screen snap

using the actual delta this casewise causes false
preference for window snapping (less to move)
this restores the pre snap-to-content behavior
in that regard and delta isn't used for anything else.
FIXED-IN: 4.11
REVIEW: 111139

M  +4    -4    kwin/geometry.cpp