When pressing "Quick tile window to the left/right" on a window that is maximized, the window becomes de-maximized, but not tiled to the left/right. Only after pressing the shortcut a second time, the window gets tiled the the left/right. This is a regression / change in behavior since 5.8.5, where the call of the shortcut immediately resulted in the tiling to the left/tight. The same situation occurs for applications which are tiled to the left/right, closed and re-started afterwards. The tiled window state usually gets restored after the restart. However, if the window was tiled to the left and now I press the shortcut to tile it to the right (or vice versa), it becomes de-maximaized. Before plasma 5.9.0 it got immediately moved it to the other half of the screen. Please restore the old behavior.
I'm seeing this behavior too, though for the tiling behavior by dragging the window to a screen edge. It happens also for windows that were tiled when opened and not just the maximized ones. This is ArchLinux package.
I suspect that this is caused by ``` commit 9934f5b57537feae54afd0c4366c90253638ada2 Author: Martin Gräßlin <mgraesslin@kde.org> Date: Fri Sep 16 14:27:50 2016 +0200 Properly implement maximize of ShellClient Summary: This brings some more checks from Client to ShellClient. Thus the states are better adjusted. Unfortunately the X11 implementation is also slightly adjusted, so could create regressions in worst case. BUG: 368393 Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3507 ``` And I assume this might be one of the "worst case". The following patch seems to fix the issue for me locally though I'm not sure if it's the right solution. I'll submit a review if no one proposed a better solution in a few days. ``` diff --git a/geometry.cpp b/geometry.cpp index 64b5d67ca..420549aeb 100644 --- a/geometry.cpp +++ b/geometry.cpp @@ -3333,11 +3333,11 @@ void AbstractClient::setQuickTileMode(QuickTileMode mode, bool keyboard) m_quickTileMode = QuickTileNone; // Temporary, so the maximize code doesn't get all confused setGeometry(electricBorderMaximizeGeometry(keyboard ? geometry().center() : Cursor::pos(), desktop()), geom_mode); } + setMaximize(false, false); + // Store the mode change m_quickTileMode = mode; - setMaximize(false, false); - emit quickTileModeChanged(); return; ```
Yes I also suspected that this commit is the one causing the regression. What we need is a test case which clearly shows the problem and ensure that we don't break again. After all for Wayland Windows we have that already 😉
Does KWin support automatic testing on X now? Also does that change look correct? The symptom AFAICT is definitely that `m_quickTileMode` is changed from `0` to `1` (or the other way around, don't remember) after `setMaximize` returns.
Git commit 8b4f284249f1ff6a52b7148c0536164c42ceaa73 by Martin Gräßlin. Committed on 14/02/2017 at 06:29. Pushed by graesslin into branch 'Plasma/5.9'. [autotests] Add test case for quick tiling on X11 Exposes our regressions of X11 quick tiling when a window is vertically maximized. M +1 -1 autotests/integration/CMakeLists.txt M +183 -0 autotests/integration/quick_tiling_test.cpp https://commits.kde.org/kwin/8b4f284249f1ff6a52b7148c0536164c42ceaa73
> Does KWin support automatic testing on X now? yes it can :-)
This bug is still present in plasma 5.9.3. Yichao, did you ever get around to submitting your patch?
No, there's a slightly different behavior that I cannot fix even with my patch so I didn't submitted it (the behavior might be new in 5.2). This time, instead of simply untile (and doesn't move), it does not resize (and didn't receive any restore size signal as printing in kwin code shows) when I drag it but restores it's original (untiled) size when I try to tile it. The difference of the end result is that the window is moved, but the size is still wrong.
*** Bug 376224 has been marked as a duplicate of this bug. ***
Moving `setMaximize(false, false);` further up (to revert the problematic commit) seems to fix the issue on my kwin 5.9.4/openSUSE 42.2. ``` --- a/geometry.cpp 2017-03-21 21:54:36.000000000 +0800 +++ b/geometry.cpp 2017-03-23 19:11:02.872123167 +0800 @@ -3326,6 +3326,8 @@ TabSynchronizer syncer(this, TabGroup::QuickTile|TabGroup::Geometry|TabGroup::Maximized); + setMaximize(false, false); + if (mode != QuickTileNone) { m_quickTileMode = mode; // decorations may turn off some borders when tiled @@ -3336,8 +3338,6 @@ // Store the mode change m_quickTileMode = mode; - setMaximize(false, false); - emit quickTileModeChanged(); return; ```
This bug is still present in fedora and arch.
(In reply to sedrubal from comment #11) > This bug is still present in fedora and arch. Of course it is, if it were fixed it would be marked as fixed.
Why is this bug still "UNCONFIRMED"? And Platrform is not only Gentoo, but also fedora, arch and most likely all distros ;)
(In reply to sedrubal from comment #13) > Why is this bug still "UNCONFIRMED"? That's probably the most often question we get: unconfirmed has no meaning at all on bugs.kde.org. It is only there for $REASONS.
*** Bug 380005 has been marked as a duplicate of this bug. ***
*** Bug 380468 has been marked as a duplicate of this bug. ***
*** Bug 381824 has been marked as a duplicate of this bug. ***
@Till The version field "defines the version of the software the bug was (first) found in.", hence you should leave to 5.9 and not bump the version...
*** This bug has been marked as a duplicate of bug 376104 ***