Bug 289494 - Alt+Left-click on a maximized window immediately restores it to smaller size
Summary: Alt+Left-click on a maximized window immediately restores it to smaller size
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 222100 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-12-21 12:13 UTC by Syam
Modified: 2013-06-30 18:51 UTC (History)
4 users (show)

See Also:
Latest Commit: http://commits.kde.org/kde-workspace/aa5e49e25fb803b42d60147d409404f017854764
Version Fixed In: 4.11
Sentry Crash Report:

Attachments
work in progress patch (1015 bytes, patch)
2012-09-20 08:35 UTC, Nikola Kovacs 		Details
work in progress patch (1.74 KB, patch)
2012-09-20 08:38 UTC, Nikola Kovacs 		Details
Work in progress patch (1.74 KB, patch)
2012-09-20 08:41 UTC, Nikola Kovacs 		Details
Show Obsolete (2) View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Syam 2011-12-21 12:13:32 UTC 
Version:           unspecified (using KDE 4.7.3) 
OS:                Linux

When Alt+Left-clicking a maximized window, it is restored to its smaller size, as if an Alt+Drag operation is about to happen.
Should this happen on just clicking the window? I think the resizing should happen only if there's an actual dragging.

Reproducible: Always

Steps to Reproduce:
Maximize a window
Alt+Left-click on the window

Actual Results:  
The window is un-maximized

Expected Results:  
Nothing happens
Comment 1 Martin Flöser 2011-12-21 20:34:51 UTC 
At the moment I would call it the correct behavior and not a bug. Nevertheless I agree that this is not optimal, so I change to wishlist and will try to have a look at it.

A possible implementation would affect the movement of all windows when alt+click is used. It is questionable whether an instant move is expected and the drag distance is not needed.
Comment 2 Thomas Lübking 2012-03-11 04:18:12 UTC 
*** Bug 222100 has been marked as a duplicate of this bug. ***
Comment 3 Nikola Kovacs 2012-09-20 08:34:58 UTC 
The best solution would be to require a certain threshold to be passed before the window is unmaximized.
I did manage to hack kwin to require the mouse y position to be greater than 48 before unmaximizing (this doesn't fix this bug, but it does fix bug 222100, and it probably wouldn't be hard to change this to an offset threshold), but the window does not restore correctly. It restores and then immediately resizes to the maximized size. I'll try to figure out why, but I'll attach the work in progress patch in case someone wants to check it out.
Comment 4 Nikola Kovacs 2012-09-20 08:35:51 UTC 
Created attachment 74045 [details]
work in progress patch
Comment 5 Nikola Kovacs 2012-09-20 08:38:40 UTC 
Created attachment 74046 [details]
work in progress patch

Previous patch was in wrong format

Patch is against KDE 4.9.1
Comment 6 Nikola Kovacs 2012-09-20 08:41:10 UTC 
Created attachment 74047 [details]
Work in progress patch

and that one was reversed... sorry
Comment 7 Thomas Lübking 2012-09-20 10:40:01 UTC 
please don't attach patches (they will just get lost herre, promised), but make a review request on git.reviewboard.kde.org
Comment 8 Nikola Kovacs 2012-10-11 14:26:44 UTC 
Sorry for the wait, review request is live:
https://git.reviewboard.kde.org/r/106796/
Comment 9 Thomas Lübking 2013-06-05 12:37:32 UTC 
Git commit aa5e49e25fb803b42d60147d409404f017854764 by Thomas Lübking.
Committed on 14/03/2013 at 21:54.
Pushed by luebking into branch 'master'.

block quick tiling unless actually moved

REVIEW: 109485
FIXED-IN: 4.11

M  +13   -2    kwin/events.cpp
M  +14   -25   kwin/geometry.cpp

http://commits.kde.org/kde-workspace/aa5e49e25fb803b42d60147d409404f017854764
Comment 10 Nikola Kovacs 2013-06-30 18:51:40 UTC 
KDE 4.11 works great with Chrome, no more annoying unmaximizations. Thanks!