Bug 505684

Summary: Windows pinned to appear on multiple virtual desktops don't sync position and size once they are either Quick or Custom Tiled
Product: [Plasma] kwin Reporter: dmatteo002
Component: Quick TilingAssignee: KWin default assignee <kwin-bugs-null>
Status: CONFIRMED ---    
Severity: normal CC: aapm_px123, alexwreyem, breakingspell, burneddi, cachorroamarelo8000, captain, daninshed, dmatteo002, elrobo, fk, john.kizer, juanmireles, k.kde.lcyet1pss9eaila9icuq, kde-forum.legible343, kristen, lynn, mail, steve, suciuandrei2003, s_chriscollins, treble-acid-copied, wears.monarch_5c
Priority: NOR    
Version First Reported In: 6.4.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=505685
https://bugs.kde.org/show_bug.cgi?id=506058
https://bugs.kde.org/show_bug.cgi?id=506056
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Bug with systemsettings windows

Description dmatteo002 2025-06-17 08:14:38 UTC
Created attachment 182322 [details]
Bug with systemsettings windows

SUMMARY
Windows on multiple virtual desktop don't sync position and size, allowing windows to be tiled in one and floating in another, and also have different sizes.
Note, this is probably related to per virtual desktop tiling (which caused other similar bug).

STEPS TO REPRODUCE
1. Open an app
2. Right click on the window decoration
3. Desktop -> all desktop (or select 2 virtual desktop)
4. Tile in a virtual desktop
5. move to another virtual desktop and untile it and move it/resize it
6. go back to original virtual desktop

OBSERVED RESULT
The windows on different virtual desktop have different size and tile status. That cause some problem: sometime they have different position, sometime they are synced (eg. when both are floating), switching from one to another cause the app to be bugged in size until the transition end,...

EXPECTED RESULT
Window on multiple virtual desktop should have position synced (or while i'm against it, consistently have different size and tile,...)

SOFTWARE/OS VERSIONS
Operating System: KDE neon Unstable Edition
KDE Plasma Version: 6.4.80
KDE Frameworks Version: 6.16.0
Qt Version: 6.9.0
Kernel Version: 6.11.0-26-generic (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7735HS with Radeon Graphics
Memory: 16 GiB of RAM (14,9 GiB usable)

ADDITIONAL INFORMATION
Also present in Arch 6.4 beta.
Comment 1 S. Christian Collins 2025-06-19 11:18:33 UTC
This bug completely messes up my workflow. I always tile Dolphin and Kate to the top and bottom of my secondary screen, with both apps set to "all desktops". This means that no matter what desktop I switch to, my file browser and text editor always stay put. However, with Plasma 6.4, once I switch desktops, both apps change to a completely different position when I switch to another virtual desktop.

Beyond fixing the bug, I'd actually like to see a configuration option to disable per-desktop tiling layouts. I can think of many reasons a person might prefer a simpler, singular tiling configuration, and that would certainly work around this particular issue for my use case.
Comment 2 Lynn T. 2025-06-20 05:25:42 UTC
I can confirm this a very unexpected result of the 6.4 update for my use-case. 
I keep my windows visible on all virtual desktops by default, using the Window Rules functionality of Plasma. I use quick tile to quickly get my windows to the size and positions I want. 
This allows me to disable the "on all desktops" attribute of windows in specific tiles to be able to rotate between different applilcations. For example on the bottom of my rotated center screen, I have Dolphin pinned to one virtual desktop, my music player on the next, EasyEffects after that, and my email client on the final one. I can cycle between these applications and only have that specific tile change, while keeping the position of my web browser, terminal, youtube window, discord, video game all stationary. 
While I think this is a welcome feature, it certainly causes issues with the way I had my Plasma setup. 

A possible work around I believe that can fix my issue is to remove all my virtual desktops, recreate the tiles I had previous to the update, and then go back to my additional virtual desktops. I am worried this may not work however, and each new desktop will just default to the standard 3-horizontal setup that comes default on Plasma. 

I agree with Christian Collins that this would be something that absolutely can be toggled on or off somewhere. Perhaps someone knows of a way to disable this without patching the source code?
Comment 3 John Kizer 2025-06-23 15:12:58 UTC
I can reproduce this in Fedora KDE 42, Plasma 6.4.0. Thanks!
Comment 4 S. Bryant 2025-07-15 07:27:19 UTC
This bug appeared for me in the recent 6.4 update; I'm using OpenSUSE Slowroll.

It's quite jarring and unexpected, as windows no longer stay where you put them, which is quite unintuitive.  In my case, the window I use for video calls should be in the same place on all desktops.  If I manually size and position the window, it stays where it is - so this bug effectively breaks tiling.

I'd be OK with this functionality staying in, as long as it's:
a. configurable
b. not the default
Comment 5 Kristen McWilliam 2025-07-21 15:27:28 UTC
I believe this regression was introduced with https://invent.kde.org/plasma/kwin/-/merge_requests/6893
Comment 6 Alex Meyer 2025-07-21 20:26:00 UTC
For anyone else like me that's desperate for any kind of workaround until this bug is resolved, I ended up throwing together a really hackish kwin script to fix my biggest annoyances with this behavior:
https://github.com/reyemxela/kwin-scripts (specifically the "virtual-desktop-tiling-fix" script)

It basically just intercepts any window tiling action and instantly removes the tile assignment while keeping the new geometry. Any tiling action triggers it, so quick-tiling with meta+arrows, dragging into custom tiles, etc.

Obviously it's not very elegant, and causes some side effects. The most obvious ones are windows not snapping back to their original geometry when moving them out of that tiled zone, along with successive quick-tiling commands getting funky.

TLDR: it's not a good solution for most people. It's pretty specific for my use-case and the behavior I'm needing, but figured if it can help even one person, it's worth sharing until this bug gets addressed.
Comment 7 Datenfalke 2025-09-05 15:36:57 UTC
I have this problem in KDE neon with Plasma 6.4.4 and it breaks my workflow with my left and right monitor containing the same tiled (messengers etc.) windows on each virtual desktop.
Comment 8 Patrix 2025-11-04 07:00:52 UTC
So here we are in Plasma 6.5.1(at least in Fedora 42)... annnnd still no fix. Not going to lie, it's really frustrating, also I'm really starting to question the priorities here.
Comment 9 dmatteo002 2025-11-10 12:06:45 UTC
Will also add that this cause the overview effect to only show the windows on virtual desktop that have the same position and size of the last selected virtual desktop
Comment 10 grog 2025-11-13 22:22:09 UTC
It's disappointing that such a fundamental change in how window management works got pushed without any settings/toggle to go along with it. I've been monitoring this since it broke my workflow several months ago and recently I decided to try and fix it myself, but while I am still interested in learning and contributing code, it's become apparent that it will take me much longer to learn how to fix this than I'd hoped. Meanwhile I'm chasing my windows around my screens just trying to multitask how I used to.

I am still planning on spending whatever free time I can spare to learn to contribute to this awesome project, but if anybody with more experience comes across this, please can you add a toggle or straight up revert this commit? 
https://invent.kde.org/plasma/kwin/-/commit/d1ba02494378649330cf71da8eacf8b74c29e0c7
Comment 11 Datenfalke 2025-11-14 11:17:52 UTC
Using KDE Plasma 6.5.2 in KDE neon the error is also still there. It is really a window chasing and silly rearranging *everytime* I use my system after standby. I sometimes let the computer running and wasting energy just to not have my windows totally mixed up :-(
Comment 12 grog 2025-11-14 14:33:09 UTC
(In reply to Kristen McWilliam from comment #5)
> I believe this regression was introduced with
> https://invent.kde.org/plasma/kwin/-/merge_requests/6893

Just replying to bury my comment with this better link
Comment 13 S. Christian Collins 2025-11-14 15:39:00 UTC
Prior to this regression, I would have Dolphin and Kate (both pinned to all desktops) tiled one above the other on my secondary monitor. However, since this is now unworkable due to this bug, I have implemented a workaround using kdotool to set each window to the desired size and position. Here is my method:
1. Set Dolphin and Kate pinned to all desktops using Window Rules in System Settings.
2. Install kdotool.
2. Create a launcher script for each application to set the window to the desired location and size. You will need to modify the application name, window title and coordinates for your own use case (copy the text between the horizontal dash lines):

------------------------------------------------------------------------
# Launch Dolphin
dolphin &

# Wait for the Dolphin window to be ready
while ! kdotool search "— Dolphin" | head -c1 | grep -E '.'
do
    sleep 1
done

# Set the position and size for the Dolphin window
kdotool search "— Dolphin" windowmove 1920 137
kdotool search "— Dolphin" windowsize 1280 591
------------------------------------------------------------------------

The use of the em dash + space ("— ") in the window title search is for windows whose titlebar usually includes both a file name or path and the application name (e.g., "Home — Dolphin"). Adding the em dash prevents kdotool from moving the Kate window instead in cases where—for example—I have a Dolphin launcher script loaded into Kate, since the Kate titlebar at that point reads "launch_dolphin.sh — Kate".

I hope this helps someone.