Bug 279529

Summary: kwin no longer unsets the maximized state when making a maximized window smaller
Product: [Plasma] kwin Reporter: Halla Rempt <halla>
Component: generalAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: cfeck, hanswchen
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Halla Rempt 2011-08-06 13:37:35 UTC
Version:           unspecified
OS:                Linux

Until 4.7, if I maximazed a window and then dragged it smaller, it would lose it's maximized status. When pressing maximize again, it would the maximize. Now it returns to some vague un-maximized state that often the windows hasn't been in anymore.

Reproducible: Didn't try

Steps to Reproduce:
Enable window resizing when maximized. Open a window. Maximize it, then drag one of the borders to make the window smaller. Press maximize again/

Actual Results:  
The window is restored to some unmaximized state, as if it was still really maximized.

Expected Results:  
The window should be maximized again, as in KDE before 4.7.

It adds a keystroke to my usual workflow, I now have to press F12 (maximize) twice now to get the effect I want.
Comment 1 Christoph Feck 2011-08-06 14:15:59 UTC
Might be the cause for bug 279451 (which I believed was a kdeui problem...)
Comment 2 Thomas Lübking 2011-08-06 15:25:37 UTC
The general behaviour is intended (a window is maximized because it's maximized and not because it has a certain geometry) but in fact it should loose the maximize state when resized (and pot. moved) by the user.

I don't think this is the (direct) cause of #279451 - it happens with openbox as well (big window -> maximize state)

Actually -with the kwin maximize/geometry unlink- rather the opposite should happen, so i guess the client sets itself maximized instead of taking a specific size (but would have to trace to be sure)
Comment 3 Halla Rempt 2011-08-06 15:35:39 UTC
Well... I think the pre KDE 4.7 behaviour made more sense from my point of view as  a user. 

I doubt it's the application itself causing this behaviour, because it happens with all KDE applications, but also firefox and xterm. But maybe you were talking about bug 279451 in that paragraph...
Comment 4 Thomas Lübking 2011-08-06 15:41:56 UTC
> Well... I think the pre KDE 4.7 behaviour made more sense from my point of 
> view as a user.

Behaviour: Yes.
Implementation: No.
Whether a window is maximized (and can be restored to another size) or randomly takes that space is not the same (and caused enough side effect bugs)
-> fix will be to restore the old behaviour (in this context) by altering the correct window flag at appropriate times (which an implicit user hint as resizing a max'd window clearly is)

Should end up in 4.7.1.

> But maybe you were talking about bug 279451 in that paragraph...
Yes.
Comment 5 Halla Rempt 2011-08-06 16:26:23 UTC
Cool, that will make me so happy! Thanks!
Comment 6 Thomas Lübking 2011-08-15 20:15:38 UTC
Git commit 3700951ab33933c707da2e50b0561bf3ee9812c4 by Thomas Lübking.
Committed on 09/08/2011 at 22:43.
Pushed by luebking into branch 'KDE/4.7'.

fix movable maximized behaviour, allow maximizing clients with limited max size

BUG: 279529
REVIEW: 102237

M  +25   -23   kwin/geometry.cpp

http://commits.kde.org/kde-workspace/3700951ab33933c707da2e50b0561bf3ee9812c4
Comment 7 Thomas Lübking 2011-08-15 21:03:15 UTC
Git commit 362a438ba7fd7c9d682632386644b5f7b7e4fe82 by Thomas Lübking.
Committed on 09/08/2011 at 22:43.
Pushed by luebking into branch 'master'.

fix movable maximized behaviour, allow maximizing clients with limited max size

BUG: 279529
REVIEW: 102237
(cherry picked from commit 3700951ab33933c707da2e50b0561bf3ee9812c4)

M  +25   -23   kwin/geometry.cpp

http://commits.kde.org/kde-workspace/362a438ba7fd7c9d682632386644b5f7b7e4fe82
Comment 8 Thomas Lübking 2011-08-23 21:02:24 UTC
Git commit ea91e9dea63cf58fcf0d45d7e2f4783d0b70b8bb by Thomas Lübking.
Committed on 23/08/2011 at 22:51.
Pushed by luebking into branch 'KDE/4.7'.

check workspace position after screen change of any max'd client

also only unset max'd state when resizing, but not when moving a max'd client
BUG: 279051
CCBUG: 279529
REVIEW: 102414

M  +1    -1    kwin/client.h
M  +11   -5    kwin/geometry.cpp

http://commits.kde.org/kde-workspace/ea91e9dea63cf58fcf0d45d7e2f4783d0b70b8bb
Comment 9 Thomas Lübking 2011-08-23 21:45:59 UTC
Git commit 7142d5557d252f21ec739352708520e4d9fe64d4 by Thomas Lübking.
Committed on 23/08/2011 at 22:51.
Pushed by luebking into branch 'master'.

check workspace position after screen change of any max'd client

also only unset max'd state when resizing, but not when moving a max'd client
BUG: 279051
CCBUG: 279529
REVIEW: 102414
(cherry picked from commit ea91e9dea63cf58fcf0d45d7e2f4783d0b70b8bb)

Conflicts:

	kwin/geometry.cpp

M  +1    -1    kwin/client.h
M  +11   -5    kwin/geometry.cpp

http://commits.kde.org/kde-workspace/7142d5557d252f21ec739352708520e4d9fe64d4
Comment 10 Hans Chen 2011-09-08 17:34:30 UTC
"also only unset max'd state when resizing, but not when moving a max'd client"

May I ask why it's unset only during resizing and not moving? I use "Maximize windows by dragging them to the top of the screen" on my Netbook plus BorderlessMaximizeWindows=true. Before I could drag a maximized window to restore it (Alt+left mouse button or drag empty space; very practical since the window border is hidden), but now the window stays maximized when I drag.

Note that this only happens with the BorderlessMaximizeWindows=true option.
Comment 11 Thomas Lübking 2011-09-08 19:25:03 UTC
No idea why the Borderles.... breaks "quick unmaximization" in this regard but this behavior is not intended - dragging from QM should always unmax' and restore the former geometry.

Was the former geometry actually restored before the change?
Comment 12 Thomas Lübking 2011-09-08 21:16:54 UTC
figured it. unrelated to this particular change but triggered with the same commit that (validly) causes a changeMaximize() from checkWorkspacePosition() which itself is called from setNoBorder()

see https://git.reviewboard.kde.org/r/102555/
Comment 13 Hans Chen 2011-09-08 22:16:15 UTC
Wow, thanks for the incredibly fast fix, you're awesome!
Comment 14 Thomas Lübking 2011-09-09 16:20:07 UTC
Git commit 5ca44bfd7dce34504ff5fdc25818470bc672e358 by Thomas Lübking.
Committed on 08/09/2011 at 23:05.
Pushed by luebking into branch 'KDE/4.7'.

catch changeMaximize recursion from setNoBorder

polluted the restore geometry for unmaximizing from quick maximization when using BorderlessMax'd

CCBUG: 279529

M  +8    -2    kwin/geometry.cpp

http://commits.kde.org/kde-workspace/5ca44bfd7dce34504ff5fdc25818470bc672e358
Comment 15 Thomas Lübking 2011-09-09 18:15:25 UTC
Git commit 6c00100d09c9b088585cb17bf06d9732c760490c by Thomas Lübking.
Committed on 08/09/2011 at 23:05.
Pushed by luebking into branch 'master'.

catch changeMaximize recursion from setNoBorder

polluted the restore geometry for unmaximizing from quick maximization when using BorderlessMax'd

CCBUG: 279529
(cherry picked from commit 5ca44bfd7dce34504ff5fdc25818470bc672e358)

M  +8    -2    kwin/geometry.cpp

http://commits.kde.org/kde-workspace/6c00100d09c9b088585cb17bf06d9732c760490c
Comment 16 Hans Chen 2012-02-11 20:50:25 UTC
Unfortunately I still have problem with "quick unmaximization" when moving windows in 4.8. Should I file a separate bug report?
Comment 17 Thomas Lübking 2012-02-11 21:18:25 UTC
Well, is it *this* problem? (or actually the one raised in comment #10)
Otherwise, yes - please file a new issue for other issues with "quick unmaximization"
Comment 18 Hans Chen 2012-02-11 21:48:07 UTC
It's the one in comment #10, so I've filed a separate report as Bug 293864. Thanks for the fast response!