SUMMARY Need the option to completely disable the new tiling features. They are not desirable nor functionally usable for all users, myself included. In particular the tiling 'snap-window-to-adjacent-windows' then resizing affects them all at once. It could be argued that the new tiling features should be opt-in and not enabled by default as they break/change the previous experience/workflow. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.26.90 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION Siduction (Debian sid base)
It is opt in.
The 'coordinated resize for adjacent/tiled windows' feature cannot be disabled by any setting I can find, it's always enabled. I have not enabled any tiling options nor can I find any such. Using the tiling editor doesn't seem to affect anything, and disabling the editor likewise seemingly has no effect. So how exactly would I disable the tiling?
> So how exactly would I disable the tiling? The new behavior is intentional and there's no option to disable it. We can reconsider it if there are legit UX arguments in favor of it
This functionality is not desired and breaks my workflow, it's very disruptive so a way to disable it is highly requested. Forcing users to adapt to new functionality which drastically changes basic features is not the way KDE Plasma should progress IMHO, that's more akin to how GNOME abuses its users. If you need to go about it in this way then an opt-out would suffice.
5.27.2 still does not have an option to disable tiling. If this the improper place to track this, please close this report and direct me to where such a feature request should be made.
Here's a broken UX flow: you now cannot use the mouse to create a split screen of two windows on top of each other. Previous steps to have a window cover the top half of a screen, using only the mouse: - drag the window to the upper left corner so it becomes tiled - drag the right edge of the window to the right edge of the screen Current steps to have a window cover the top half of the screen, using only the mouse: - you cant. you. cant. - the window refuses to be resized beyond some point because it has to maintain space for the non-existent tile beside it Here's another broken ux flow: you can't drag 3 windows to be side-by-side, because as soon as one of them snaps into tiling with another, they move in tandem and you can't create a gap between them for the third window. Honestly I agree with OP, this feature is a degraded UX. It was a much more satisfying interface to have each window snap to a particular location agnostic of and without modifying other window positions. Also, not being able to drag a window edge beyond some arbitrary point on my screen is an absurd and frustrating experience.
Created attachment 157587 [details] Demostration of UX issue I've attached a GIF that attempts to illustrate why this is a UX issue for some users. In short, the assumption is being made that if two windows are adjacent and sharing a boundary, that it's automatic for resizing one window to automatically resize the other. But that isn't always what users want. See the gif for an example. A solution to this might be to either have an option to disable this assumption, or an option to have this assumption only applied while holding down a hotkey for example (shift/ctrl/etc) while resizing a window.
A workaround for this seems to be using diagonal resizing from the corner touching the border instead of just horizontal or vertical resizing. This way kwin doesn´t save space for inexistent tiled windows. Note that use diagonal resizing from the corner that is in the middle of the screen will also limit the maximum size of the window. It only works if you resize the window from the corner that touches the border. This also works for the case exposed on the last comment of two adjacent windows when one needs to overlap the other. But when an option to ignore tiles when resizing exist, it doesn't seem to be very intuitive as you need to experiment with all the resizing options an notice that particular behaviour. I agree that an option directly exposed to the user would be nice.
*** This bug has been marked as a duplicate of bug 465937 ***