SUMMARY If I use shortcuts to tile a window, for example into a corner of the screen. Then maximize and unmaximize it, it does not restore into the corner but instead into the last manually adjusted position/size. STEPS TO REPRODUCE 1. Open a window 2. move it into the center of the screen 3. Move it into the right using a keyboard shortcut Meta+right 4. Maximize it by double clicking the title bar 5. Undo maximizing by double clicking the title bar again OBSERVED RESULT Window is back in the center EXPECTED RESULT Window should be at the right side Operating System: Manjaro Linux KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 Kernel Version: 5.4.67-1-MANJARO OS Type: 64-bit Processors: 16 × AMD Ryzen 7 1800X Eight-Core Processor Memory: 62,8 GiB of RAM Graphics Processor: Radeon RX 580 Series ADDITIONAL INFORMATION
Yes, this is a minor bug. Un-maximizing returns to the last state that was neither maximized nor tiled, rather than returning to the prior state, whatever that is.
I hope "minor" here means easy to fix, not unimportant. As you normally use Quick tile shortcuts if you have the need to organize your windows and this kinda throws a big wrench into archiving this objective.
Code-wise, this is totally intended behavior.
Any update on that bug? I absolutely second cysliders justification, this bug really messes up KDE shortcut based workflows. Not sure what is meant by "totally intended behavior", could you elaborate on this?
He means that from a developer perspective, this isn't a bug but rather intentional behavior. Someone programmed the feature to work this way. From your (and my) perspective it is a bug, though. Intended behaviors that are annoying can be changed.
Got it, thanks for the heads-up. I was afraid this was the case and consider this a bug as well since I couldn't thing of a single use case where this behaviour would make sense. The title of this says it already, it's an inconsistent and intuitive behaviors, the user needs to keep track if he used a quicktile shortcut to know what's gonna happen when restore window size. Who wants to do that!? Maybe whoever made this decision could explain any use-cases? Happy to be persuaded. However, at the very least there should be an option to change this behavior, i.e. treat quicktile shortcuts the same as manual resizing.
This current behaviour makes it hard to use tiling, because you can not maximize/unmaximize a window, without getting a floating window again.
*** Bug 475063 has been marked as a duplicate of this bug. ***
Created attachment 165806 [details] Video of "resize" workaround For now I'm using "Resize Window" shortcut/action as a workaround. Caveats: - Tested on KDE Plasma 6.0 RC2 and 1920x1080 display resolution - It works mostly for bigger tiles (e.g. 2 windows tiled vertically in half) - This trick breaks simultaneous resizing of tiled windows (that was introduced in Plasma 5.27) How to (also see attached screencast): 1. Assign some shortcut (e.g. Meta+Ctrl+s) for "Resize Window". it can be set at "System Settings" > "Keyboard" > "Shortcuts" > "KWin") You can also assign something like Meta+Ctrl+w for "Move Window" action 2. Tile windows and adjust their sizes 3. Use keyboard only (don't use mouse or touchpad) for the next steps 4. After switching to the tiled window, press "Resize Window" shortcut (if it wasn't set, press Alt+F3 to activate window menu, and use keyboard arrows to find and activate "Resize" window action). 5. The cursor will move automatically to the lower right corner of the window, ready for resize 6. Don't resize window, just "Enter" or "Space" to confirm. 7. Use "Move"/"Move Window" window action or shortcut for a test. After "Move window" activation, window will either move temporally to different location or stay in place. Either way, you can restore previous ("tiled") window location by pressing "Esc" key. If window temporally changes location during "Move Window" activation, then this "resize" workaround wouldn't help, and after "Maximize"/"Unmaximize" window will be moved to the inappropriate location.