Trying to move a window to the left border of my leftest monitor sometimes sends the window to the wrong place, e.g. to the top right corner of that monitor - even tho the preview indicates it would snap into the right place. On second try it usually works fine.
Please provide the output of: qdbus org.kde.KWin /KWin supportInformation
Version ======= KWin version: 5.9.0 Qt Version: 5.8.0 Qt compile version: 5.8.0 XCB compile version: 1.12 Operation Mode: X11 only Build Options ============= KWIN_BUILD_DECORATIONS: yes KWIN_BUILD_TABBOX: yes KWIN_BUILD_ACTIVITIES: yes HAVE_INPUT: yes HAVE_DRM: yes HAVE_GBM: yes HAVE_X11_XCB: yes HAVE_EPOXY_GLX: yes HAVE_WAYLAND_EGL: yes X11 === Vendor: The X.Org Foundation Vendor Release: 11901000 Protocol Version/Revision: 11/0 SHAPE: yes; Version: 0x11 RANDR: yes; Version: 0x14 DAMAGE: yes; Version: 0x11 Composite: yes; Version: 0x4 RENDER: yes; Version: 0xb XFIXES: yes; Version: 0x50 SYNC: yes; Version: 0x31 GLX: yes; Version: 0x0 Decoration ========== Plugin: org.kde.breeze Theme: Blur: 0 onAllDesktopsAvailable: true alphaChannelSupported: true closeOnDoubleClickOnMenu: false decorationButtonsLeft: 0, 1, 2 decorationButtonsRight: 6, 3, 4, 5 borderSize: 3 gridUnit: 10 font: Noto Sans,10,-1,5,50,0,0,0,0,0 smallSpacing: 2 largeSpacing: 10 Options ======= focusPolicy: 0 nextFocusPrefersMouse: false clickRaise: true autoRaise: false autoRaiseInterval: 0 delayFocusInterval: 0 shadeHover: true shadeHoverInterval: 250 separateScreenFocus: false placement: 4 focusPolicyIsReasonable: true borderSnapZone: 2 windowSnapZone: 2 centerSnapZone: 0 snapOnlyWhenOverlapping: false rollOverDesktops: true focusStealingPreventionLevel: 1 legacyFullscreenSupport: false operationTitlebarDblClick: 5000 operationMaxButtonLeftClick: 5000 operationMaxButtonMiddleClick: 5015 operationMaxButtonRightClick: 5014 commandActiveTitlebar1: 0 commandActiveTitlebar2: 30 commandActiveTitlebar3: 2 commandInactiveTitlebar1: 4 commandInactiveTitlebar2: 30 commandInactiveTitlebar3: 2 commandWindow1: 7 commandWindow2: 8 commandWindow3: 8 commandWindowWheel: 31 commandAll1: 10 commandAll2: 3 commandAll3: 14 keyCmdAllModKey: 16777251 showGeometryTip: false condensedTitle: false electricBorderMaximize: true electricBorderTiling: true electricBorderCornerRatio: 0.25 borderlessMaximizedWindows: false killPingTimeout: 5000 hideUtilityWindowsForInactive: true inactiveTabsSkipTaskbar: false autogroupSimilarWindows: false autogroupInForeground: true compositingMode: 1 useCompositing: true compositingInitialized: true hiddenPreviews: 1 glSmoothScale: 2 xrenderSmoothScale: false maxFpsInterval: 16666666 refreshRate: 0 vBlankTime: 6000000 glStrictBinding: true glStrictBindingFollowsDriver: true glCoreProfile: true glPreferBufferSwap: 101 glPlatformInterface: 1 windowsBlockCompositing: true Screen Edges ============ desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: 1x1 timeThreshold: 150 reActivateThreshold: 350 actionTopLeft: 0 actionTop: 0 actionTopRight: 0 actionRight: 0 actionBottomRight: 0 actionBottom: 0 actionBottomLeft: 0 actionLeft: 0 Screens ======= Multi-Head: no Active screen follows mouse: no Number of Screens: 3 Screen 0: --------- Name: DisplayPort-0 Geometry: 0,0,3840x2160 Refresh Rate: 59.9966 Screen 1: --------- Name: HDMI-0 Geometry: 5760,856,1920x1080 Refresh Rate: 60 Screen 2: --------- Name: DVI-1 Geometry: 3840,856,1920x1080 Refresh Rate: 60 Compositing =========== Compositing is active Compositing Type: OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CAPE VERDE (DRM 2.48.0 / 4.9.6-1-ARCH, LLVM 3.9.1) OpenGL version string: 4.3 (Core Profile) Mesa 13.0.4 OpenGL platform interface: GLX OpenGL shading language version string: 4.30 Driver: Unknown GPU class: Unknown OpenGL version: 4.3 GLSL version: 4.30 Mesa version: 13.0.4 X server version: 1.19.1 Linux kernel version: 4.9.6 Direct rendering: Requires strict binding: yes GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no OpenGL 2 Shaders are used Painting blocks for vertical retrace: no Loaded Effects: --------------- zoom slidingpopups kwin4_effect_login screenshot kwin4_effect_windowaperture kwin4_effect_translucency minimizeanimation kwin4_effect_fadedesktop desktopgrid colorpicker kwin4_effect_morphingpopups kwin4_effect_maximize kwin4_effect_fade presentwindows highlightwindow kwin4_effect_dialogparent blur contrast startupfeedback screenedge kscreen Currently Active Effects: ------------------------- blur contrast Effect Settings: ---------------- zoom: zoomFactor: 1.2 mousePointer: 0 mouseTracking: 0 enableFocusTracking: false followFocus: true focusDelay: 350 moveFactor: 20 targetZoom: 1 slidingpopups: fadeInTime: 150 fadeOutTime: 250 kwin4_effect_login: screenshot: kwin4_effect_windowaperture: kwin4_effect_translucency: minimizeanimation: kwin4_effect_fadedesktop: desktopgrid: zoomDuration: 300 border: 10 desktopNameAlignment: 0 layoutMode: 0 customLayoutRows: 2 usePresentWindows: true colorpicker: kwin4_effect_morphingpopups: kwin4_effect_maximize: kwin4_effect_fade: presentwindows: layoutMode: 0 showCaptions: false showIcons: false doNotCloseWindows: true ignoreMinimized: false accuracy: 20 fillGaps: true fadeDuration: 150 showPanel: false leftButtonWindow: 1 rightButtonWindow: 2 middleButtonWindow: 0 leftButtonDesktop: 2 middleButtonDesktop: 0 rightButtonDesktop: 0 highlightwindow: kwin4_effect_dialogparent: blur: blurRadius: 12 cacheTexture: true contrast: startupfeedback: type: 1 screenedge: kscreen:
Any chance to test with Qt 5.7? We have regressions in Qt 5.8 in other areas and I consider it as highly unlikely that our code broken given that quick tiling is completely under test coverage (at least the Wayland part and X11 didn't change).
Understood, but I'm afraid I won't be able to do this anytime soon.
Are the windows you are trying to quick tile maximized vertically or horizontally? If yes this could be bug #376224
Not sure whether you mean before or after tiling, so to clarify: I'm trying to tile a non-maximized window to the left border of my screen (so it would become vertically maximized).
non-maximized as in free floating or maybe touching some edges? We have a vertical maximized state which is not the quick tiling
Usually close to a screen corner, but certainly nowhere near touching it (at least 16px margin).
Confirmed as still existing with Qt 5.9.
Still present with KWin 5.10.3 and Qt 5.9.1 More-detailed repro steps: 1) Open a Konsole window. This matters. With many (all?) KDE applications, and some others, this bug occurs. With urxvt or claws-mail, it doesn't. 2) Drag it to the middle-right edge of the screen, so it snaps to the right half. 3) Close the window. 4) Open a new Konsole window. 5) Drag /that/ to the middle-right edge again. Observe that it snaps to a different area, usually one of the left corners. With some non-KDE apps (Chromium, qutebrowser) it snaps to the top-right corner instead.
*** Bug 376155 has been marked as a duplicate of this bug. ***
*** Bug 384552 has been marked as a duplicate of this bug. ***
*** Bug 384745 has been marked as a duplicate of this bug. ***
*** Bug 385192 has been marked as a duplicate of this bug. ***
*** Bug 376224 has been marked as a duplicate of this bug. ***
*** 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. ***
Migrating info from duped bugs: This seems to have been caused by https://cgit.kde.org/kwin.git/commit/?id=9934f5b57537feae54afd0c4366c90253638ada2 The following quick-and-dirty patch seems to resolve it for some people: --- 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; Martin, since we do have test cases for X11 now, is this something we can get submitted to Phabricator as a patch?
(In reply to Nate Graham from comment #19) > Martin, since we do have test cases for X11 now, is this something we can > get submitted to Phabricator as a patch? No as it does not address the reasons on why the code was moved in first place. Just reverting a commit does not fix things, it causes issues in other places.
(In reply to Nate Graham from comment #19) --- kwin-5.11.0/geometry.cpp 2017-10-12 15:13:48.467815000 +0300 +++ kwin-5.11.0/geometry.cpp 2017-10-12 15:13:34.340537140 +0300 @@ -3355,6 +3355,8 @@ if (maximizeMode() != MaximizeRestore) { TabSynchronizer syncer(this, TabGroup::QuickTile|TabGroup::Geometry|TabGroup::Maximized); + + setMaximize(false, false); if (mode != QuickTileMode(QuickTileFlag::None)) { m_quickTileMode = mode; This patch fixes the issue in 5.11.0. Tested in Archlinux.
The bug I originally reported, https://bugs.kde.org/show_bug.cgi?id=376224, marked as a duplicate of this one, isn't solved in 5.11.0 (KDE Neon). If I tile a vertically maximized window, instead of tiling it, it brings it back to its original (pre-maximized) dimensions.
Antoscha, it looks like that simple fix doesn't address Martin's concerns.
The simple fix does not address the problem why the code changed like that in the first place. If we revert that part we just run into issues elsewhere in the code. We need a complete solution taking care of the required behavior on X11 and Wayland.
*** Bug 385904 has been marked as a duplicate of this bug. ***
I have a similar issue with kwin 5.10.5 on Debian Testing Linux. I have quick tile shortcuts assigned to Meta+Up/Down/Left/Right and whenever I attempt to quick-tile a maximized window via shortcut, it de-maximizes before I am able to quick tile it. If I activate the shortcut a second time, the window tiles as expected.
Created attachment 109016 [details] Proposed patch Attached is a patch built up on the suggestions we had so far. The suggestions didn't work, it broke existing test cases. This patch fixes the issue according to the tests and does not introduce regressions in other tests. Please give it a try.
I applied the patch here on kwin 5.11.3 running on xorg-server 1.19.5 and it works like a charm.
Git commit 8a2796d280dd7e891724cb6e6d873a57e2ae8c52 by Martin Flöser. Committed on 04/12/2017 at 16:25. Pushed by graesslin into branch 'master'. Fix regression from KWin 5.9 regarding quick tiling Summary: The regression got introduced with 9934f5b57537feae54afd0c4366c90253638ada2. The order when setMaximize(false, false) was called changed in regard to when the quick tiling mode was adjusted. But just changing the ordering back was no solution as that would cause regressions in other areas (unit tests fail). This change builds up on the support for geometry update blocker on Wayland to be able to better support this situation without causing further regressions. Also this change rethinks the code area. There is an idea behind temporarily setting the quick tile mode to none and that is even documented in a comment: it should not confuse maximize. So let's do exactly that: call the maximize in the block where the quick tile mode is temporarily wrong. As that is only one branch the else branch performs the same steps. FIXED-IN: 5.12.0 Test Plan: Confirmation in bug report that patch fixes issue Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D9178 M +0 -16 autotests/integration/quick_tiling_test.cpp M +8 -5 geometry.cpp https://commits.kde.org/kwin/8a2796d280dd7e891724cb6e6d873a57e2ae8c52
Currently using Fedora 35 and it seems this bugged behavior has returned at some point. Using a keybind to quick tile a currently maximized window causes the window to unmaximize but not tile as desired until a subsequent quick tile bind is pressed. Has anyone else run into this issue?
Can you please file a new bug report and put it in the "See also" field for this one?
Don't have this issue on Manjaro testing, plasma 5.23.5.
The bug's returned for me as well, at least on wayland, plasma 5.24.1. Was another report ever filed?