Bug 323855

Summary:	Dragging window by title bar makes grips work improperly against desktop corners
Product:	[Plasma] kwin	Reporter:	Andrew Udvare <audvare>
Component:	multi-screen	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	normal
Priority:	NOR
Version:	4.11.0
Target Milestone:	---
Platform:	unspecified
OS:	Linux
URL:	http://i.imgur.com/u4sfH0y.jpg
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Andrew Udvare 2013-08-21 19:13:58 UTC

If you have window tiling (which I believe is the default), gripping between windows is inconsistent between when you drag using the title bar and when you use the grips on the side.

If I drag a window using the corners to resize it, it grips to the sides of the desktop (screen) fine. But if I use the title bar, the border does not seem to count as part of the window and gets dragged off screen.

I have a dual monitor set up with one monitor 2560x1600 and on the right is a laptop at 1280x800. So, the bottom border of Konsole is gripped into 'dead space' and the right side is gripped off by the border. I can see the right border of Konsole on my second monitor.

Again this is inconsistent because I can use the corner grips to get what I do want. But the problem with that is possibly losing the precise size I want for the window.

This may or may not require a dual monitor configuration.

Reproducible: Always

Steps to Reproduce:
1. In System Settings, set up dual monitor configuration with second monitor moved x pixels right by however many pixels the first monitor is. Example for me: 2560 x and 0 y.
2. Open a window, not maximised and drag it using its title bar to the bottom right corner in an attempt to line the window's bottom right corner with the same corner on the desktop.
Actual Results:  
The window corner should align perfectly with the same desktop corner.

Expected Results:  
The border gets ignored in determining gripping.

Comment 1 Thomas Lübking 2013-08-21 20:10:56 UTC

Can you please check whether you're referring to https://git.reviewboard.kde.org/r/112103/  ie. that windows snap to the client instead of the decoration even on inner screen borders?

Snapping to the client instead of the decoration (on moving and at least outer borders) is intentional
Snapping to the client on resize is not reasonbly "possible" (on single screen setups) since the mouse cannot leave the screen, thus cannot be kept in sync with the decoration when moving it out of the screen.

Comment 2 Andrew Udvare 2013-08-21 20:23:15 UTC

Now I noticed that maximising a window pretty much removes the borders. This seems kind of okay although with a theme like Keramik it does not look very good because the borders are rounded.

If this is intentional, I do not see why this cannot be an option in system settings. I think borders look better, even when maximised and especially like I said for a theme like Keramik with rounded corners.

Comment 3 Andrew Udvare 2013-08-21 20:31:55 UTC

Also could it not be possible to instead make it easy to snap at 2 different edges, one border edge and then inner (without border)? This is the behaviour that Chrome/Chromium seems to have with KDE (even with its tiny border).

Comment 4 Thomas Lübking 2013-08-21 20:42:05 UTC

The border state of maximized windows is unrelated - the deco simply hides it. This behavior is controlled by the decoration, just a state that was (widely) abused as hint on what to do is now gone (for other reasons)

The patch in the review already includes double snapping, but personally i consider the behavior odd and contraproductive, since snapping to the "right" pixel now becomes an obstacle (esp. when the decoration is thin)

Comment 5 Andrew Udvare 2013-08-21 22:13:50 UTC

When I get a chance, I will try the patch (on 4.11) and report back.

One thing I do like is that right now (in 4.11 release) is the 'feature' where using the mouse to drag the window size (to expand its width) makes the window snap at the screen edge (aligning with the decoration, not the contents). I would hope this is not going away. And it seems like the patch does not affect this behaviour.

Comment 6 Andrew Udvare 2013-08-21 22:15:26 UTC

By the way, feel free to mark this as a duplicate of 323504

Comment 7 Thomas Lübking 2013-08-22 10:03:05 UTC

Resizing is not affected by any change since, as mentioned, its mouse constrained (actually we would not have to even snap to outer screen borders on resize at all)

We'd move the deco out of sync with the mouse position and the "active" item out of screen - neither is reasonable.

*** This bug has been marked as a duplicate of bug 323504 ***