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.
Might be the cause for bug 279451 (which I believed was a kdeui problem...)
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)
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...
> 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.
Cool, that will make me so happy! Thanks!
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
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
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
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
"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.
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?
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/
Wow, thanks for the incredibly fast fix, you're awesome!
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
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
Unfortunately I still have problem with "quick unmaximization" when moving windows in 4.8. Should I file a separate bug report?
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"
It's the one in comment #10, so I've filed a separate report as Bug 293864. Thanks for the fast response!