Cannot reproduce. Can you write expanded steps to reproduce starting from a clean desktop with no windows open so I can follow it exactly? Alternatively, a screen recording would help.

Created attachment 156405 [details]
Demonstration of the issue

I've added a video where you can see the issue. I tile to the left (super+left), horizontal resize (super+right click), and now I'm stuck with these strange sizes on all subsequent quick tiles to the left and right, including after closing the window and opening a new one.
I forgot to include it in the recording but like I mentioned, regular behavior can be restored by running "kwin_x11 --replace".
Also of note, I temporarily moved my .cache, .config and .local to make sure it's not some broken config issue.

This is intentional behavior in 5.27. Resizing a tiled window changes the split between left half of the screen and the right half of the screen so if you have two windows tiled side by side, they cover the entire area of the screen.

Closing the tiled windows and the state persisting just doesn't make any sense. I think on windows 10 for example, you can do something similar where windows snapped to the sides fill the remaining space, but new windows snapped on an empty desktop still take half.

Why would anyone want to preserve the invisible layout that cannot be reset? Wouldn't the people who want persistent tiling layouts be using the new custom tiling thing anyway?

Is there any way to disable this. Like not making the window a 'tiled' window' and retain the ability to position windows to the left and right half of the screen?

Agreed, this bug should be reopened. The 50 / 50 layout is a separate layout from the Win + T layouts, and as such we can't really reset it. I am okay with the state persisting if there was a way to reset, but currently there isn't.

I tend to agree that preserving the split while there aren't tiled windows seems wrong because the behavior is invisible and non-resettable. It seems okay to preserve it as long as there are at least one quick-tiled window on either side of the split, but once that ceases to be the case, the split should reset to its midpoint position.

The name "Quick Tiling"e even communicates that this is a short-term transient thing; if you want a more permanent setup, you should use the new Custom Tiling system.

Re-opening.

@Nate Graham, I think that's a perfect way to do it!

*** Bug 466817 has been marked as a duplicate of this bug. ***

One more +1 to make this quick tiling behavior optional, it's driving me nuts. I have a setup w/ 1440p screen, an instant messenger open in a 640px wide bar to the left, 1920px wide browser/editor/whatever to the right that I overlay with other windows 50/50, and trying to mix this 50/50 on top of the 640+1920px windows gets weird results (let's say I have a 1920px wide browser and want to overlay 50% wide PDF browser - nope, it'll force it into the 640px bar, you have to first resize any window manually to "undock" the window from the quick tiling state).

Raising priority as this is rather annoying and we're getting a lot of negative feedback about it. If adjacent quick-tiled windows are supposed to resize together now, it doesn't work reliably and predictably enough to seem like a feature; instead it seems like a bug. In my recent experience, it feels like anytime I *want* my adjacent quick-tiled windows to resize together, they don't, and then later windows will resize together or quick-tile to unexpected regions in a way that feels quite random.

+1 Hi! KDE is amazing, and thanks for making it! Please make this behavior, if it is intentional, optional. I would kindly want every time I click Meta+Right the window should be placed exactly at the right exact half of the screen every time, irrelevant if it was resized, or full screen, or anything. Please kindly add an option to make it possible, it is a really simple behavior. Thank you.

(In reply to Kamil Cukrowski from comment #12)
> I would kindly want every time I click Meta+Right the window should be placed exactly at the right exact half of
> the screen every time, irrelevant if it was resized, or full screen, or
> anything

Hi Kamil - me too! A bit of experimenting has shown that if you open the tiling interface (Meta+T) and delete all the tiles, all of the quick-snapping features behave like they used to in pre-5.27.

I'm sure this feature will help a lot of people, but it is confusing that our existing bindings' behaviour changed without any explanation. Hopefully the KDE team can find a way to allow the two features to coexist, or at least make the onboarding experience less jarring.

> if you open the
> tiling interface (Meta+T) and delete all the tiles, all of the
> quick-snapping features behave like they used to in pre-5.27.

Not for me ( kwin 5.27.5 ). There were actuyll no tiles in the Meta-T view in the first place after updating to 5.27.

One more related issue:

1. Quick tile a window to the left or write, it doesn't matter.
2. Swtich to another desktop (e.g., from 1 to 2)
3. Quick tile one more window.
4. Resize 2nd window
5. Get back to desktop 1.

You'll see that 1st window also was suddenly resizes.

I don't think it's an expected behaviour. Resizing windows belonging to one desktop should not impact on windows on other desktops.

*** Bug 464950 has been marked as a duplicate of this bug. ***

If this is intentional behavior, please add a way to disable it. It's driving me nuts.

This issue is really driving me nuts, up the wall wanting to pickup my laptop and throw out of the window nuts.

sorry for the previous line. But when using meta+shortcuts for all default old posisionts icm the the "new" tiling system is really broken.

Please remove or make it configurable that there is no persistent configuration for the quick tile posistions. If you want persistant, make it available through the editor, every other change (99.99999% times it's an unintentional change in my case).  and the whole setup becomes unusable again. 

1. when temporary resizing a window, it should not snap a random  window  in the background to the window an resize that to the window. 
2 resizing the window to 3 quarter of the screen, also results that when I use Meta End to the bottem right quarter screen, results in a window with the left top placed on 3/4 of the screen, but the window isn't resized the rest of the window is off screen.

Please restore the old method, of make it configurable that the only persistant window arrangement is the one done through the editor. The current system is unworkable.

I would also like to see this be reverted or configurable. I understand the desire here and it makes sense to me—to effectively "set up" a custom layout. However, I'm used to the old behaviour; I used it very frequently, and I want a quick way to just make a window take up half of the screen, no matter how I subsequently resized windows afterward.

I agree that this should be optional. It feels unintuitive and more like a bug than a feature.

+1 been driving my crazy for months. Today I tried some workaround. This kinda works (https://github.com/acristoffers/kwin-rectangle) but it is also not as good as the previous behavior. I just want to snap windows to half my screen.... even if I previously manually resized a window. I am going nuts here. I am to the point that I really need to train myself to NEVER resize a window, which is sad because occasionally you do want a window larger than half. I miss the old functionality so very much.

I also dread accidentally triggering this feature. 

If I trigger it I have to close all windows, open four Konsole windows in each corner of the screen and use the row/column indicator in each Konsole window to ensure they're all 50% screen height and 50% screen width.

I once found the configuration file where the dynamic tiling is stored, deleting that file and rebooting reverted the split back to 50/50. I can't remember which file it was though.

Every time it happens I think about dumping KDE, not because this is a bad idea just that it has been so badly implemented. 

KDE used to be famous for configuration and customisation then we get this invisible feature (I don't even know what it's called!).

This  may not be a solution for everyone, but just having a setting that always forces 50% for tiling would make me happy, then it would behave like it did previously.

+1 for the general complaints. Please implement possibility to:

- disable automatic resize of two adjacent quick-tiled windows
- disable automatic resize of quick tiled windows on all virtual desktops

I'm a recent KDE user, and generally love it, but this behavior alone has me considering changing DE/WM again after just a couple months.

(In reply to jake gaisser from comment #23)
> This  may not be a solution for everyone, but just having a setting that
> always forces 50% for tiling would make me happy, then it would behave like
> it did previously.

+1 This would be great. I snap windows around constantly and always want them to snap 50%. I often adjust the width afterwards and am usually okay with windows overlapping some. It's a nice way to keep track of what's there while getting the full view when focusing it.

Changes like this subvert the utility of so many of the concepts of a normal windowing system. We shouldn't be forced into tiling.

(In reply to Nate Graham from comment #7)
> I tend to agree that preserving the split while there aren't tiled windows
> seems wrong because the behavior is invisible and non-resettable. It seems
> okay to preserve it as long as there are at least one quick-tiled window on
> either side of the split, but once that ceases to be the case, the split
> should reset to its midpoint position.
> 
> The name "Quick Tiling"e even communicates that this is a short-term
> transient thing; if you want a more permanent setup, you should use the new
> Custom Tiling system.
> 
> Re-opening.

100% agree with Nate, I don't think this needs new configurable settings. The split position should reset to 50% once all windows have been closed or "un-splitted".

(In reply to alberto.rinaudo from comment #26)
> (In reply to Nate Graham from comment #7)
> 100% agree with Nate, I don't think this needs new configurable settings.
> The split position should reset to 50% once all windows have been closed or
> "un-splitted".

That would be intuitive for one desktop. If you use many it will still be very annoying. So it should then be a state per desktop, or there should be a way to turn it off.

I'd be really grateful to have a setting to disable this feature.

Maybe related: even after moving all windows around, I can't get the tiling back to 50/50. And Meta+T does nothing.
Ftr, I'm on Fedora 38. I'll probably update to F39 during the week.

@Samantaz Fox, you can try to undock windows by holding a keyboard shortcut to resize a window, then resizing a window by two sides. If you do it on both sides, it should reset back to 50/50 - if it doesn't, I just log out and back in :( It's really annoying.

We used it as a torture tool at work to get suspects to talk and it worked well beyond our expectations !
Thank you very much, however if it is possible to be able to reattribute the old behavior which works just magnificently for the innocent people who didn't ask for anything, it would be really appreciated.

I honestly don't understand how it could have seemed like a good idea to you to deploy this as is by completely removing a functionality that was otherwise useful and fonctional.

+1 For this to be reverted or configurable.

I downgraded KDE when this first appeared and I'm disheartened to discover that months later there is still not a solution. Please allow the old quick-tile behavior; I really have so much muscle-memory built around it. (https://github.com/acristoffers/kwin-rectangle is a serviceable workaround but resizing after using it is currently buggy for me.)

*** Bug 476474 has been marked as a duplicate of this bug. ***

To me there should be a config option for this 2 things (probably separately):
  - quick tiling forced to 50% width
  - disable of any width change to other windows

I used to use it as follows:
  - quick tile both windows to 50%
  - resize them to ~75% to still allow quick switching (click on the backgrounded window) and having reasonable work space.

Now this workflow is broken (seems not only for me). Please add config options for these. We don't want to be forced to do anything.

(In reply to WiseLord from comment #15)
> One more related issue:
> 
> 1. Quick tile a window to the left or write, it doesn't matter.
> 2. Swtich to another desktop (e.g., from 1 to 2)
> 3. Quick tile one more window.
> 4. Resize 2nd window
> 5. Get back to desktop 1.
> 
> You'll see that 1st window also was suddenly resizes.
> 
> I don't think it's an expected behaviour. Resizing windows belonging to one
> desktop should not impact on windows on other desktops.

Also experiencing this one. Most definetly a bug

(In reply to Norbert from comment #33)
> To me there should be a config option for this 2 things (probably
> separately):
>   - quick tiling forced to 50% width
>   - disable of any width change to other windows
> 
> I used to use it as follows:
>   - quick tile both windows to 50%
>   - resize them to ~75% to still allow quick switching (click on the
> backgrounded window) and having reasonable work space.
> 
> Now this workflow is broken (seems not only for me). Please add config
> options for these. We don't want to be forced to do anything.

This WAS exactly my workflow as well. So I too would wish this permanent and 'sticky' window snapping would be optional (or reverted). After snapping, I wish to be able to freely resize the windows again. As far as I've found, this is not possible anymore. Resizing (from the center of the screen) always has a consequence on the other windows, even newly snapped windows. That's horrendous for me.

+1

Have noticed this particular bug, it's annoying when it doesn't reset when there are no "snapped" windows left. META+t doesn't correspond with the tiled windows, so there's nothing I can do there.

Side note:  Firefox doesn't allow any resizing while being snapped to a side or corner.

For a solution, instead of a single, mutable split stop, could it remember however many stops as have been created by resizing, plus an immutable 50/50 stop, so that Meta + Arrow keys could cycle through those before moving to opposite edges and adjacent screens? The resizing of adjacent windows could also be limited to only the last most recently used windows that are snapped to both an opposite edge/corner and the shared edge of the window being resized. Windows behind those would remain untouched but could, of course, be snapped to the new stop by the user. Unused stops would need to be garbage collected, otherwise there would still be the reported memory effect and the possible stops would grow out of control.

For getting around the current problem, I found an accurate way to reset to 50/50 is to use KRuler:
1. snap it to a side
2. press D to change direction if 0 is not at the screen's edge
3. resize it to half your monitor resolution
4. hover your mouse over the last pixel to check its exact length
5. repeat steps 3 & 4 until it's correct

It's quite a frustrating UX.

I also wanted this functionality back so badly that I found a solution that "works for me" and that I'd like to share.

As a hack, you can recompile kwin with the following patch applied.
Then any move/resize takes the window out of the tiled state and the original 50/50 split never gets modified.
But you have to live with a brief flicker on resizing a tiled window, and recompiling kwin on every new release.

---

diff --git a/src/window.cpp b/src/window.cpp
index 8d93a514b0..0fa8922cb8 100644
--- a/src/window.cpp
+++ b/src/window.cpp
@@ -1650,7 +1650,7 @@ bool Window::startInteractiveMoveResize()
         }
     }
 
-    if (m_tile && !m_tile->supportsResizeGravity(interactiveMoveResizeGravity())) {
+    if (m_tile) {
         setQuickTileMode(QuickTileFlag::None);
     }

(In reply to Nebelbank from comment #38)
> I also wanted this functionality back so badly that I found a solution that
> "works for me" and that I'd like to share.
> 
> As a hack, you can recompile kwin with the following patch applied.
> [...]

Works like a charm!
1000 thanks! :-)

Tested on Debian-12

(In reply to Nate Graham from comment #7)
> I tend to agree that preserving the split while there aren't tiled windows
> seems wrong because the behavior is invisible and non-resettable. It seems
> okay to preserve it as long as there are at least one quick-tiled window on
> either side of the split, but once that ceases to be the case, the split
> should reset to its midpoint position.
> 
> The name "Quick Tiling"e even communicates that this is a short-term
> transient thing; if you want a more permanent setup, you should use the new
> Custom Tiling system.
> 
> Re-opening.

(In reply to alberto.rinaudo@gmail.com from comment #26)
> 100% agree with Nate, I don't think this needs new configurable settings.
> The split position should reset to 50% once all windows have been closed or "un-splitted".

+1 for this. I use quick tiling the entire time when using Plasma or Windows. I also get fairly annoyed by the current behaviour as it does cost me time -- not a lot, but a little every day. It is nice to be able to move the divider so that all tiled windows change size at the same time, but it's annoying to not be able to quickly restore the default divider positions.

I agree with both Nate and Alberto, I don't think this initially needs new complicated configuration options.

Instead, I have four (fairly simple?) suggestions to make it easy and intuitive but provide flexible options, and I really hope someone reads them:

1) There should be an easy keyboard shortcut to reset both horizontal and vertical dividers to the default/50%. Meta+Shift+T might be an option as it's currently unused as far as I can see. Any currently tiled windows should resize to fit. This would work exactly the same as clicking and dragging on the dividers with the mouse, but it has the set, round 50% target size. Note that if this and/or 2) are implemented, 3) is less urgent or possibly even unnecessary!

2) Shift + Double-Left-Click on a divider (see 4. for why shift) should also reset that specific divider (not both) to the default/50%.

3) Ideally, as others have said, the quick tiling configuration should only be persistent across "tiling sessions" rather than kwin sessions. The location of the vertical and horizontal dividers for the quick tiling should reset to the default/50% whenever there are no more tiled windows on screen. Detiling all tiled windows should reset it, it shouldn't be necessary to close the windows. Minimized tiled windows still count as tiled.

4) Clicking and dragging the edge of tiled windows should do different things depending on whether Shift is being held or not. I suggest moving the divider should be done with Shift + Left-Click & Drag (analogous to Shift while moving windows to tile them) while doing it without Shift should resize it individually in the normal manner. The window would also become detiled if its size was changed in this way -- which is already exactly what happens if you click and drag on any of the window's other borders that aren't the divider.

On this last idea, it could in theory be the other way round. However, I think the way I suggest is better because I think that resizing normal windows, tiled windows, and "snapped" (placed next to each other or resized till the window borders "snap" to one another) windows should all behave identically. If you snap two windows together and then adjust the edge of one, the other one doesn't change size -- they continue to act independently.

(Incidentally, for complete consistency it would also be cool if two snapped windows could be resized at the same time by holding Shift while moving the dividing border.)

(In reply to matterhorn103 from comment #40)
> (In reply to Nate Graham from comment #7)

I still think there needs to be a configuration option to turn this functionality off.

The problem with the current functionality and these suggestions are that they are not obvious to a user. There is no on-screen feedback that smart this smart tiling is in effect (I still don't know what the official name of this functionality is).

The current functionality and your suggestions rely on a user having prior knowledge of why their windows are no longer tiling to  50%/50%. Even if they work that out they will then need to discover new key combinations that override this confusing behaviour.

I love shortcut keys but there also needs to be a simple option for users who don't care about this functionality at all and just want 50/50 splits.

(In reply to Riku from comment #2)
> [...]
> I forgot to include it in the recording but like I mentioned, regular
> behavior can be restored by running "kwin_x11 --replace".

I tried this with https://neon.kde.org/ (KDE-Plasma-6.0.2)
There "kwin_x11 --replace" doesn't work.
And using "kwin_wayland --replace" crashed all non-KDE applications including Firefox :-/

So there's probably also a bug in "kwin_wayland --replace".

(In reply to Josh from comment #41)
> (In reply to matterhorn103 from comment #40)
> > (In reply to Nate Graham from comment #7)
> 
> I still think there needs to be a configuration option to turn this
> functionality off.
> 
> The problem with the current functionality and these suggestions are that
> they are not obvious to a user. There is no on-screen feedback that smart
> this smart tiling is in effect (I still don't know what the official name of
> this functionality is).
> 
> The current functionality and your suggestions rely on a user having prior
> knowledge of why their windows are no longer tiling to  50%/50%. Even if
> they work that out they will then need to discover new key combinations that
> override this confusing behaviour.
> 
> I love shortcut keys but there also needs to be a simple option for users
> who don't care about this functionality at all and just want 50/50 splits.

Naturally, the non-visibility of the feature is an issue, I agree.

However, if specifically my 4th suggestion were to be implemented -- that the tiling divider is only moved when a border is clicked and dragged while also holding Shift, otherwise a normal resize of the window results -- then the behaviour *is* effectively turned off by default. Users won't accidentally end up in the "non-50:50" situation at all, because they need to use Shift to make it happen, so it won't happen unless they already know about the feature. No one would "need to discover new key combinations that override this confusing behaviour." , because the "confusing behaviour" would require the Shift key as an "opt-in", as it were. Meanwhile, people who do want it to work as it does now could continue using it.

The problem with the "simple option" of on/off toggle is that it doesn't offer anything for people, like myself, who often find it useful but usually find it an annoyance. Going into the settings to change it is inconvenient. It is a nice feature that I often use! It just needs to follow Plasma's mantra of "Simple by default, powerful when needed". :)

We have been suffering with these tiling changes for 1 year now and they persist in plasma 6.

Use use Meta+LeftArrow and Meta+RArrow all the time but I often end up with the situation where they are consider adjacent windows and resizing one resizes both.

We NEED a way to disable this adjacent window resizing or a way to restore the old behavior where adjacent windows do NOT affect each other.

I end up closing the apps to break the connection and reopening a total waste of time especially if I am in the middle of something.

Resizing the apps does not always work and I sometimes have a situation where I have an app in the bottom left corner and another window that is the right 50% of the screen and I try to resize the window that is on the right 50% and the app in the left corner springs back to using the left 50% of the screen.

I was SO MUCH time dealing with this, it is beyond frustrating !!!!

Please provide a way to disable the new tiling OR at a minimum how to disable the adjacent window resizing.

Even Microsoft Windows provides the basic functionality to turn OFF the adjacent snapping which I immediately do.

@matterhorn The problem with adding modifiers and new shortcuts as a solution is that they're not as naturally discoverable, and the Tiling Editor also uses Shift + drag.

@Joe S I agree there needs to be a pref to disable adjacent window resizing for quick-tiled windows.

I still think the 50:50 + self-pruning extra stops would be great & it would be immediately discoverable through existing shortcuts.

The Tiling editor is good but it's not the same: windows must be dragged to snap, only one regular layout can be in effect, layouts can't be saved, and trying to emulate multiple simultaneous layouts by using overlapping floating tiles gives a pretty rough result.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5665

As of https://invent.kde.org/plasma/kwin/-/merge_requests/5665#note_931328