Bug 321325

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")

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.

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?

See also bug 318107.

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.

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)

> 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

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?

(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".

The misunderstanding was between me and Christoph about Y or Z axis.
X axis been irrelevant in the first place ;-P

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

http://commits.kde.org/kde-workspace/736cbd016f18ea13d8da4afe3b0f7bb2ec549918