Version: (using KDE KDE 3.3.2) Installed from: Debian stable Packages OS: Linux I'm admittedly still on Debian Stable, that is, 3.3.2, but reviewing the 3.4 changelog, it seems the functionality I'd like isn't there either. I'm not quite sure what component to submit this against, but I guess it would span many different, so here goes: In Xinerama mode, it seems that you get one virtual desktop for one screen combination, so if you switch desktop, both screens switch. I now run without Xinerama mode, in which case I get two rather independent Desktops, they have a Kicker each and everything. I think the ideal is somewhere in the middle: What would be really nice if there were a common set of virtual desktops for both screens, but that you could choose quite easily which screen would display the windows of which virtual desktop. That way, you could have any combination of desktops side by side, you could even switch which screen would show which desktop... :-) I think this would be really really useful. I'm fortunate enough to run two screens at 1280x1024, but it is quite clear that it will be a problem to just switch just like that for those who use different resolutions. The windows might need reorganizing, which I suppose can be tricky. Still, this is on the top of my KDE wishlist! :-)
*** Bug 122392 has been marked as a duplicate of this bug. ***
*** Bug 105254 has been marked as a duplicate of this bug. ***
*** Bug 36705 has been marked as a duplicate of this bug. ***
*** Bug 116883 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
*** Bug 115017 has been marked as a duplicate of this bug. ***
I've been thinking a bit more and have another use case. Say I have a laptop, and when I get home, I connect another screen. While on the road, I would of course only use the laptop's own screen, but getting home, I then have two screens. With the session saved, the applications I run regularly would be up in their virtual desktops, but without this feature, only on that small laptop screen. If I'd like some of them to appear on my bigger home screen, I would have to move them, which amounts to closing and restarting the application (?). The ability to simply associate a virtual desktop with any screen would thus help a lot in this case. I fully recognise that each developer best persues his own interests, unless there is money involved. I wonder if KDE has set up some kind of bounty system. Say, for example, I pledge €100 to whoever gets this feature into KDE, and a few others do the same, is that going to help?
I've created, https://bugs.kde.org/show_bug.cgi?id=134655 it's a feature request for when this wish is fulfilled but it would be good to keep it in mind if someone is implementing this.
*** Bug 141432 has been marked as a duplicate of this bug. ***
Is it the same as the bug #61606 ?
#10: No.
Has this feature been implemented for KDE4? It would still be nice if this feature can be added to KDE3 as it will take quite some time for KDE4 to reach feature parity with KDE 3.5.x.
Maybe this should be changed into a plasma feature request? I guess after three years there's not going to be someone who suddenly programs it for KDE 3 anymore. And currently it's not very visible for KDE4...
As a xmonad user, this is really a missing feature for me in KWin. For a more visual description, see http://xmonad.org/tour.html#workspace (especially the first diagram with the "portals").
I think this could make a good Google Summer of Code-project. But implemented for KDE 4, of course, not KDE 3. It is reasonably complex, so it should make a good project. It is also clearly wanted by many users, and personally, it is on the top of my wishlist. And it doesn't seem to be implemented in many other widespread systems, so it seems to be a nice progression beyond the state-of-the-art.
(In reply to comment #15) I tried implementing this when writing a new window manager from scratch--it isn't easy. Implementing it in an already-complete window manager such as KWin will be even more difficult. Because of this I believe that the task is far too large and difficult for a GSoC project.
On second thought it might not be as difficult as I first thought but it would still require changing large sections of code throughout the entire KWin codebase. The main difficulty would be working about _NET_CURRENT_DESKTOP, which is a EWMH property that tells all applications what desktop is currently visible. This property can only be a single number so some applications might break as they think they are visible but they are not (Or the other way around). Other code that will need to be changed include the window switcher, desktop switcher and all desktop switching effects such as desktop grid and the cube. For effects the best implementation would be to add support for only applying them to a single screen at a time, this means effectively abstracting the entire Xinerama configuration into making effects see them as a multihead setup. This is where I consider the task to be difficult.
What about giving every "Screen" a DESKTOP number? So a two headed machine with 4 Desktops would account 8 DESKTOPs. An application with more than one window must manage multiple desktop numbers anyway. The window manager would report the different numbers to the applications showing on that virtual desktop. If that's a property that is polled by the application then my concept would need a way to determine which app is asking and answering in some valid way: If the application is visible, return a number of a virtual desktop where it is currently shown, if it is invisible, return any number of a visible desktop.
Am I correct in assuming that to allow KWin to manage sets of visible windows based on current Activity(-ies) we will have to deal with the same _NET_CURRENT_DESKTOP limitations mentioned in comment #17?
(In reply to comment #19) > Am I correct in assuming that to allow KWin to manage sets of visible windows > based on current Activity(-ies) we will have to deal with the same > _NET_CURRENT_DESKTOP limitations mentioned in comment #17? Partly. We would still only have one visible desktop at a time and a window will only be on one desktop. So it's the other way around. As we can unmap all windows from other activities it should not become a problem. This is based on the assumption that activity != virtual desktop.
*** Bug 224691 has been marked as a duplicate of this bug. ***
This seems to be solved in an even more elegant way in KDE4.4 with plasma and activities and virtualdesktops. Tryk if you can't replicate what you are after there.
*** Bug 241839 has been marked as a duplicate of this bug. ***
Hi guys! I have a notebook and a LCD TV, attached as a second monitor. After couple of days playing around, I've found that it would be really nice if we could have two independent virtual desktops per each screen. This is because of a different usage pattern in contrast to two equal monitors. A simple workaround for me is to pin down the windows on the LCD, so they are visible on every virtual desktop. So, when I switch desktops on my first screen, the second remains the same. Of course, this ‘setup’ allows only one virtual desktop for the second screen, but it is way better for me than default setup. KDE 4.x and Plasma are very cool, but unfortunately it lacks this feature, which is most important for me.
+1 It seems the something like this is already implemented in an OpenSuSe branch: http://blogs.kde.org/node/4489 ? It would be nice it would be pulled upstream.
+1 It seems the something like this is already implemented in an OpenSuse branch: http://blogs.kde.org/node/4489 ? It would be nice it would be pulled upstream.
> It seems the something like this is already implemented in an > OpenSuse branch: > http://blogs.kde.org/node/4489 ? It would be nice it would be pulled > upstream. Given that it has been implemented by the former KWin maintainer and he has not yet supposed to merge it, I doubt it's in a usable state yet.
What about this feature? I'm really missing it, and it's last thing I need in KDE4... will it be implemented?
It is not possible to implement this feature without violating the EWMH specification (it doesn't consider that there are more than one active virtual desktops at the same time, it might cause windows to misbehave). Because of that there is no chance that this can be implemented on the base of X11. This means this feature will not be available in the 4.x lifetime of KWin. Maybe someone implements it once we are on Wayland.
Bad ;( awesomewm, xmonad and dwm can do this... so you say those WMs are bad because they break specs?
(In reply to comment #30) > awesomewm, xmonad and dwm can do this... so you say those WMs are bad > because they break specs? No that's not what I say. I do not even know whether those WMs are EWMH compliant (most likely not because the spec has been designed by developers of stacking WMs). It's the decision of the respective WM whether they support EWMH or not. We try to support EWMH.
Yes, they are complaint: http://en.wikipedia.org/wiki/Comparison_of_X_window_managers (at least awesome which i use
(In reply to comment #32) > Yes, they are complaint: Hardly, at least not in this aspect. The issues arise when other elements ("pagers", but also the desktop mousewheel feature) attempt to set the active virtual desktop ... for what screen? To do this half wise usable, one would have to establish a system where pagers can select out of n*m VDs | n: amount of screens, m: amount of VDs Whenever a VD d is selected all windows on screens s != d/m+1 are externally moved to that desktop (so they believe to be on the current desktop as they are since their internal screen related desktop was not and has to remain untouched) Outstanding -and unilaterally unsolvable- issue is to make pagers set the VD screen aware by this system (ie. if you place a pager on screen 1 with m=4, it has to select out of VD [1,4], where a pager on on screen 2 has to select out of [5,8] instead. This also holds when moving a client to a VD, while that is actually not /that/ much of a problem (if a client is moved to a VD out of its screen range, the virtual desktop is just mapped d=(s-1)*m+d%m) If you have knowledge on how to implement this feature EWMH compliant, so that compliant pagers can use it, please share that. > at least awesome which i use I beg your pardon? Awesome is a tiling WM, KWin not. You want to switch from a tiling WM to a floating one and the thing that stops you is the amount of VDs per screen????
> Awesome is a tiling WM, KWin not Actually, Kwin can do tiling, and Awesome can do floating...
On Tuesday 21 May 2013 09:23:29 you wrote: > Actually, Kwin can do tiling, and Awesome can do floating... KWin cannot do tiling and awesome is considered as primarily a tiling window manager. "Floating" is a concept from tiling window managers. A window manager like KWin is considered as a "Stacking" window manager. Just by using the word "floating" you highlighted that awesome is a tiling window manager ;-) See also http://en.wikipedia.org/wiki/X_window_manager
*** Bug 335704 has been marked as a duplicate of this bug. ***
I haven't tested by myself, but someone created a Kwin script which can be useful to you. https://github.com/dromar56/kwin-fix-dual-screens
I'm really missing this (coming from xmonad to KDE in order to use the same stuff as the rest of the company) - virtual desktops are so much less usable with dual screen with the kwin behavior (for me). > I haven't tested by myself, but someone created a Kwin script which can be useful to you. > https://github.com/dromar56/kwin-fix-dual-screens Hm, unfortunately, this doesn't exist anymore. @Josep: Do you have a clone of the repo or a new link by accident?
Would be a really nice feature to have. The slide animation for switching virtual desktops makes me dizzy as it slides over the second screen as well.
*** Bug 411924 has been marked as a duplicate of this bug. ***
(In reply to Martin Flöser from comment #29) > It is not possible to implement this feature without violating the EWMH > specification (it doesn't consider that there are more than one active > virtual desktops at the same time, it might cause windows to misbehave). > Because of that there is no chance that this can be implemented on the base > of X11. This means this feature will not be available in the 4.x lifetime of > KWin. Maybe someone implements it once we are on Wayland. Do you think it's possible to implement in terms of a KWin addon?
(In reply to Konstantin Kharlamov from comment #43) > Do you think it's possible to implement in terms of a KWin addon? No, unfortunately such things must be implemented in KWin core. :(
*** Bug 424164 has been marked as a duplicate of this bug. ***
(In reply to Martin Flöser from comment #20) > This is based on the assumption that activity != virtual desktop. This 10 year old assumption seems to crumble: bug 341143 comment #314
With Plasma Wayland, this seems like something that should be more doable now than it was in years gone by. I've been doing this on macOS for many years, and it's a major thing I miss in Plasma. On macOS, workspaces are assigned to displays, and each display has its own set of workspaces. When you plug in an external display, macOS dynamically creates a new workspace for it. You can then create more workspaces for that display. The current workspace on each display are stitched together when in "multi-display extend mode", which allows applications to move across displays seamlessly. Making an application fullscreen in macOS automatically generates a new workspace to put the application in it, allowing you to easily switch back and forth between full-screen apps and workspaces freely. This also makes it so you *always* have access to your desktop, especially if you only have a single workspace (which is the current macOS and Plasma defaults). From my attempts to port over my workflow from macOS to Plasma, these things are completely missing, which makes it frustrating for me when I do things like presentations and demos when giving talks. I often take advantage of these features to pre-prepare the second screen with everything I need to present and demo without showing the stuff on my main display or shuffling things around too much. It's also handy for being able to have something like Crunchyroll/YouTube/Hulu/Netflix/etc on the secondary display and still be able to change workspaces on the primary display while I'm doing work and watching TV. I do this fairly often when I'm doing work leisurely. My understanding is that a good chunk of this already exists in Enlightenment, but no other Linux desktop has it, which is a shame. I'd love to see this implemented for Plasma Wayland because it's a massive quality of life improvement for usability, efficiency, and desktop reliability. Note that I'm using Fedora Linux 34 with KDE Plasma, which uses Plasma Wayland by default. I'm currently using Plasma 5.22.4.
(In reply to Neal Gompa from comment #47) > From my attempts to port over my workflow from macOS to Plasma, these things > are completely missing, which makes it frustrating for me when I do things > like presentations and demos when giving talks. I often take advantage of > these features to pre-prepare the second screen with everything I need to > present and demo without showing the stuff on my main display or shuffling > things around too much. > > It's also handy for being able to have something like > Crunchyroll/YouTube/Hulu/Netflix/etc on the secondary display and still be > able to change workspaces on the primary display while I'm doing work and > watching TV. I do this fairly often when I'm doing work leisurely. > > My understanding is that a good chunk of this already exists in > Enlightenment, but no other Linux desktop has it, which is a shame. FTR, other Linux desktops do have it. I use this workflow on KDE Plasma + i3 combintation. i3 allows assigning workspaces to screens. No Wayland on that combination though :( Also Gnome has some crude analog to this: it allows to always have one workspace on non-main screen, while switching between many workspaces on the main screen.
*** Bug 450991 has been marked as a duplicate of this bug. ***
Any work being done on this?
I would love this, without it, using virtual desktops with 2+ screens (especially 3+) is almost impossible. Like every tiling wm has it, and I have bismuth for kde but this feature is missing... I hope someone wants to add this :)
For what it's worth, there's a proposed Wayland protocol that would make this workable for KWin to implement: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40
sorry, but I wrote a duplicate: https://bugs.kde.org/show_bug.cgi?id=453657
*** Bug 453657 has been marked as a duplicate of this bug. ***
*** Bug 462124 has been marked as a duplicate of this bug. ***
With Plasma's recent tiling improvements, I've seen many tiling WM users give Plasma a try. This feature would make Plasma much more welcoming for TWM users and would greatly improve usability on systems with multiple monitors.
Bump, yes please implement this! I'm using KDE inside VR with "unlimited" monitors. It would be so useful to set up each monitor as a Virtual Desktop, to have each space saveable when for restarts.
Hi Team, Can you please share if there are any plans to implement this in plasma 6? It would be great if it will be implemented.
@MrShinigami had you take a look at the already provided URL to invent.kde.org in the bug description? AFAIK, these are the current plans.
*** Bug 473586 has been marked as a duplicate of this bug. ***
is there are any plans to implement this in plasma 6?
Looks like Wayfire 0.8.0 now implements this too: https://wayfire.org/2023/10/07/Wayfire-0-8.html Perhaps their code would help come up with ideas on how to do this in KWin?
Looking at what the devs have to say here (https://youtu.be/A_i6MCSExos?t=829), it looks like with the addition of ext-workspace Wayland protocol, this might be possible with Plasma 6. It's in the "planning to support" state right now.
Linux-focused YouTuber Brodie Robertson has now published a video in which he entertainingly narrates relevant comments in this bug from the very beginning, expresses his agreement with the request itself while adding some surrounding context, and ends on a note that Cosmic DE implements workspaces per screen which will make it tempting to users who such as himself who value this functionality in a window manager. Link: https://www.youtube.com/watch?v=AmdqMFGnJlc
I would love to see this implemented as well.
+1 interest
This is the only thing that’s keeping me from using KDE. Would be great if this got implemented <3
Is there any update from the devs? Is it on the todo list, is it something they are working on or not something to expect soon? I think this is a feature that has been requested for few years now, and Mac has it implemented since so long now. I would definitely like to understand what is stopping the implementation of this feature. This is such a deal breaker for me, and I keep switching from KDE for this exact reason.
(In reply to sai from comment #68) > I think this is a feature that has been requested for few years now, Completely irrelevant > and Mac has it Also Irrelevant >I would definitely like to understand what is stopping the implementation of this feature. This is a really weird ask. The most likely answer is that people don't have time. Remember that people actually have day jobs. They by and large aren't actually getting paid. You could always put up a substantial bounty either singly or with other interested users and find out if its feasible to fund it. You could also ask how to contribute such a feature yourself. In any case nobody is going to waste their limited free time justifying it to you. >This is such a deal breaker for me, and I keep switching from KDE for this exact reason. Oh for me too which is why I use i3wm which does have this feature. Remember nobody gets paid for you using KDE so its suitability for your use case is a non-goal. Your entire post could have profitably been shorted to "Any updates on this feature?"
+1 for this feature. This is the only thing also keeping me from using KDE. I tried using KDE without this but it's pretty annoying for my usage, I even found a plugin that hacks the support for it but it feels very out of place and doesn't work well most the time. I'm using Gnome because of it, it's not perfect there, but at least is much better than in KDE. I'm software developer (mainly web, c#, go), but I know a bit of c++ (haven't touched in years though). I'm willing to help in my spare time if I get pointed in the right directions. I know this feature will probably be very complex to implement, but I can try.
(In reply to gustavogyn from comment #70) > I'm software developer (mainly web, c#, go), but I know a bit of c++ > (haven't touched in years though). I'm willing to help in my spare time if I > get pointed in the right directions. I know this feature will probably be > very complex to implement, but I can try. If no one answers (I'm not sure this thread is actively monitored), you might try sending an email to the KWin devel list asking for directions¹. If you do so, please put a link here for future reference, so that if you'd have to drop the ball, someone else could look it up and continue the work. Thanks! 1: https://mail.kde.org/mailman/listinfo/kwin
(In reply to gustavogyn from comment #70) > +1 for this feature. This is the only thing also keeping me from using KDE. Oh ya for me this is nearly the killer feature for using i3wm its much more productive to change workspaces individually.
(In reply to michael from comment #69) I understand, and I apologize for not checking my language to make sure that it wasn't coarse. I was only trying to emphasize the importance of this functionality. I know that multi-monitors is not very well supported on X11 from what I have read. But, I also did see that wlroots does allow for this implementation. I am just curious as to what the complication is, given that in Plasma 6.0 Kwin was built to run in Wayland. If it was built from ground up, then I just wanted to know any details as to what made it difficult to implement this feature. Though, I understand that a similar issue is raised in Gnome for several years as well, so is it a complication that is similar to both the DE's?
I started a Post in the "Sponsored Work" section of the Discuss KDE Forum. I plege 400 Euros to get the ball rolling on this. However It shows in the forum that around 1000 Euros is the mark where things get picked up. So please jump on board. Every bit helps. If half of you just send a 10er, we are nearly there. Please write on the discuss thread if you are willing to put money to this goal so its all in one place. I will update the main post with your contributions. Here is the thread: https://discuss.kde.org/t/bug-fix-per-screen-virtual-desktops/16241 Lets get this thing over the line.
Created attachment 169890 [details] attachment-1761586-0.html Ill pledge some. It will not be 400 though On Mon, May 27, 2024, 1:35 PM Manux <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=107302 > > Manux <manuelsoukup@gmail.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |manuelsoukup@gmail.com > > --- Comment #74 from Manux <manuelsoukup@gmail.com> --- > I started a Post in the "Sponsored Work" section of the Discuss KDE Forum. > > I plege 400 Euros to get the ball rolling on this. However It shows in the > forum that around 1000 Euros is the mark where things get picked up. So > please > jump on board. Every bit helps. If half of you just send a 10er, we are > nearly > there. > > Please write on the discuss thread if you are willing to put money to this > goal > so its all in one place. I will update the main post with your > contributions. > > Here is the thread: > https://discuss.kde.org/t/bug-fix-per-screen-virtual-desktops/16241 > > Lets get this thing over the line. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
*** Bug 491337 has been marked as a duplicate of this bug. ***
My very puristic, highly efficient workaround: . . . . . "dwl - dwm for Wayland" My setup: . . . . . 2 x 2 monitors . . . . . . . . . . with 9 "virtual desktops" each ! + run (KDE) applications as you like, ! + on the monitor you like, ! + on the "virtual desktop" you like ! + switch via keyboard: Mod-[1-9] based upon wlroots: [ https://codeberg.org/dwl/dwl ] /* tagging - TAGCOUNT must be no greater than 31 */ #define TAGCOUNT (9)
(In reply to Manfred Knick from comment #77) > . . . . . "dwl - dwm for Wayland" It is indeed very useful that KDE developers make sure that KDE applications are available on other platforms. This report, though, is about Plasma and KWin. If you are not using (or planning to use) Plasma and KWin, your input is irrelevant for this ticket.
(In reply to Oded Arbel from comment #78) > (In reply to Manfred Knick from comment #77) > It is indeed very useful that KDE developers make sure that KDE applications > are available on other platforms. Yes, *very* much appreciated, indeed! And "all the best" to KDE. > This report, though, is about Plasma and KWin. If you are not using (or > planning to use) Plasma and KWin, your input is irrelevant for this ticket. I disagree: dwl demonstrates with how few LoC the long awaited ... Have you missed the term *workaround* , or did you ignore it? As many others, I have been waiting for almost 20 (yes, twenty!) years now. Perhaps, a tiny little bit of humility might be adequate? -- No more on this from me.
The ext-workspace protocol that would help with this is now released with wayland-protocols v1.39: https://lists.freedesktop.org/archives/wayland-devel/2024-December/043920.html
I don't see a reason not to work on this now that the ext-workspaces protocol is there (KDE could end up being the first DE with proper workspaces implementation under wayland) (AFAIK the only thing out there that does this is hyprland land) (Also this bug report is literally older than me I think at this point this either needs to be closed or resolved soon)
*** Bug 509467 has been marked as a duplicate of this bug. ***
For what it's worth with Plasma 6.6 there will be a KWin script included in the kdeplasma-addons component/package that will simulate GNOME's ability to have virtual desktops only on the primary display, so any windows that get moved to secondary displays will automatically be set to appear on all virtual desktops, and if such windows get moved back to the primary display it will be set to appear only on the current virtual desktop. It's certainly not a complete fix, but it'll at least cover scenarios like keeping a video playing on a second screen while still switching between virtual desktops on the primary screen, especially in cases where there's more than one window on the second screen so setting each window to appear on all virtual desktops would be a hassle. https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/910
(In reply to Prajna Sariputra from comment #83) > For what it's worth with Plasma 6.6 there will be a KWin script included in > the kdeplasma-addons component/package that will simulate GNOME's ability to > have virtual desktops only on the primary display, so any windows that get > moved to secondary displays will automatically be set to appear on all > virtual desktops, and if such windows get moved back to the primary display > it will be set to appear only on the current virtual desktop. It's certainly > not a complete fix, but it'll at least cover scenarios like keeping a video > playing on a second screen while still switching between virtual desktops on > the primary screen, especially in cases where there's more than one window > on the second screen so setting each window to appear on all virtual > desktops would be a hassle. > > https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/910 The virtue of a workspace at all is to change sets of windows all at once with one operation rather than re-arranging many windows. I don't think what you have described is at all virtuous. You get the ability to say have a single unchanging chat or browser window alongside of your active project at the expense of using it as an extension of the windows on the primary monitor. It is also weird alongside more than one monitor. Who wants workspaces on 1 monitor and 2 static ones? One can already pin individual windows so they stick to all workspaces so simulate a similar behavior. It should make more sense to either optionally A) untether workspaces from monitors as for instance i3wm does so users can select any selection of workspaces to display at a given time. If one wants an unchanging secondary monitor one simply sets it once and then keeps changing the other monitor. If one wants to change both one does. The default gnome experience takes no additional work at all and the default plasma experience takes a few more clicks B) Better yet treat workspace pinning like pinning windows although perhaps a better visual metaphor would be a lock. Default plasma experience all locked. Given 2 monitors 1A 1B changing to workspace 2 changes to 2A 2B. Unlock one and you can have 1A 2B. Can be easily changed with a click. Plays well with more than 2 monitors and behaves consistently with a clear visual metaphor. Can be shipped with gnome or plasma default just by setting the default lock state for all monitors to be primary only or all.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/980
(In reply to Bug Janitor Service from comment #85) > A possibly relevant merge request was started @ > https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/980 Hi, I created an work-in-progress MR, but this currently waits for feedback from KWin devs, because there are some problems which I am not completely sure how to resolve.
While at it, I wonder if this bug should be added to https://community.kde.org/Plasma/Wayland_Known_Significant_Issues ? I understand formally this is an RFE, but… it's actually complicated. I've been using this feature on X11 KDE for years, because X11 allows to replace KWin with any WM that supports the feature. With 6.8 Plasma there's a plan to drop X11 support, and this means per-screen desktops will disappear from KDE. Considering this issues has 17 duplicates and 114 users, making it one of the most popular bugreports, I think this should be considered as one of blockers to dropping X11.
(In reply to Konstantin Kharlamov from comment #86) > (In reply to Bug Janitor Service from comment #85) > > A possibly relevant merge request was started @ > > https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/980 > > Hi, I created an work-in-progress MR, but this currently waits for feedback > from KWin devs, because there are some problems which I am not completely > sure how to resolve. Nice, thanks! Just one thing, I might be wrong, but from what I understood from this issue, it can't be solved by using only scripts in satisfactory manner. There needs to be some fundamental changes in Kwin, but KDE developer will give better input on this one
Upon discussing it turned out someone already made an MR a week ago¹, and their implementation seems to be more complete (for one, they already gathered feedback from the devs 😊), so I closed mine in preference of that one 1: https://invent.kde.org/plasma/kwin/-/merge_requests/8602
(In reply to Konstantin Kharlamov from comment #89) > Upon discussing it turned out someone already made an MR a week ago¹, and > their implementation seems to be more complete (for one, they already > gathered feedback from the devs 😊), so I closed mine in preference of that > one > > 1: https://invent.kde.org/plasma/kwin/-/merge_requests/8602 Oh wow, that's nice and exciting to see! I am coming from i3 and I share your feedback about the proposed implementation, wherein a desktop is bound to a monitor and switching to a desktop switches focus to it along its monitor.
(In reply to Konstantin Kharlamov from comment #87) > While at it, I wonder if this bug should be added to > https://community.kde.org/Plasma/Wayland_Known_Significant_Issues ? > > I understand formally this is an RFE, but… it's actually complicated. > > I've been using this feature on X11 KDE for years, because X11 allows to > replace KWin with any WM that supports the feature. With 6.8 Plasma there's > a plan to drop X11 support, and this means per-screen desktops will > disappear from KDE. > Keep in mind what you're doing meant it never existed in KDE. It was never supported, and this is net-new functionality for the KDE Plasma experience.
*** Bug 515868 has been marked as a duplicate of this bug. ***
Git commit 84aa3c83f5cecf16465742fbe3991218c58f86cc by Hynek Schlindenbuch. Committed on 27/03/2026 at 13:36. Pushed by davidedmundson into branch 'master'. add support for per-output virtual desktops See https://invent.kde.org/plasma/kwin/-/merge_requests/8602 M +35 -1 src/client/plasmavirtualdesktop.cpp M +20 -0 src/client/plasmavirtualdesktop.h M +1 -1 src/client/registry.cpp https://invent.kde.org/plasma/kwayland/-/commit/84aa3c83f5cecf16465742fbe3991218c58f86cc
Git commit fa6c4a424a5c8bcefddcb163852aefae8313a9a1 by Hynek Schlindenbuch. Committed on 13/04/2026 at 16:05. Pushed by davidedmundson into branch 'master'. virtualdesktops: Add per-output desktops VirtualDesktopManager now tracks the current virtual desktop separately for each output. By default it switches the desktop on all outputs together, but there is now an option to enable switching desktops separately for each output. M +5 -5 src/activation.cpp M +47 -23 src/activities.cpp M +7 -3 src/activities.h M +14 -2 src/dbusinterface.cpp M +1 -0 src/dbusinterface.h M +8 -9 src/effect/effecthandler.cpp M +14 -6 src/effect/effecthandler.h M +1 -1 src/effect/effectwindow.cpp M +3 -4 src/focuschain.cpp M +0 -7 src/focuschain.h M +2 -2 src/internalwindow.cpp M +14 -0 src/kcms/desktop/ui/main.qml M +4 -0 src/kcms/desktop/virtualdesktopssettings.kcfg M +1 -0 src/keyboard_layout_switching.cpp M +3 -0 src/kwin.kcfg M +1 -1 src/layers.cpp M +11 -0 src/options.cpp M +15 -0 src/options.h M +6 -6 src/placement.cpp M +4 -1 src/plugins/dialogparent/package/contents/code/main.js M +5 -1 src/plugins/fadedesktop/package/contents/code/main.js M +6 -1 src/plugins/frozenapp/package/contents/code/main.js M +1 -1 src/plugins/krunner-integration/windowsrunnerinterface.cpp M +1 -1 src/plugins/minimizeall/package/contents/code/main.js M +18 -10 src/plugins/overview/overvieweffect.cpp M +3 -3 src/plugins/overview/overvieweffect.h M +40 -16 src/plugins/overview/qml/Main.qml M +160 -35 src/plugins/slide/slide.cpp M +68 -30 src/plugins/slide/slide.h M +13 -2 src/plugins/tileseditor/qml/Main.qml M +6 -2 src/plugins/translucency/package/contents/code/main.js M +15 -3 src/plugins/windowview/qml/Main.qml M +5 -0 src/scene/windowitem.cpp M +8 -7 src/screenedge.cpp M +1 -1 src/scripting/desktopbackgrounditem.cpp M +23 -1 src/scripting/workspace_wrapper.cpp M +17 -1 src/scripting/workspace_wrapper.h M +2 -2 src/tabbox/tabbox.cpp M +1 -1 src/tiles/tile.cpp M +7 -4 src/tiles/tilemanager.cpp M +8 -8 src/useractions.cpp M +171 -59 src/virtualdesktops.cpp M +57 -12 src/virtualdesktops.h M +45 -1 src/wayland/plasmavirtualdesktop.cpp M +12 -0 src/wayland/plasmavirtualdesktop.h M +2 -2 src/waylandwindow.cpp M +43 -5 src/window.cpp M +4 -1 src/window.h M +31 -24 src/workspace.cpp M +7 -6 src/workspace.h M +13 -5 src/x11window.cpp M +9 -0 src/xdgshellwindow.cpp https://invent.kde.org/plasma/kwin/-/commit/fa6c4a424a5c8bcefddcb163852aefae8313a9a1
And with those plus other commits, this is done!
Note that the merge request intentionally had the CCBUG label instead of the BUG label to avoid auto closing this bug report, since there was some debate on whether the use cases some people actually want from per-screen virtual desktops would be covered by the implementation as it stands (one specific example I saw is that it's not possible to switch focus to both a specific virtual desktop *and* a specific display in one go). I myself am quite happy with the way it is in git master now, so I'm not personally objecting to this bug report being closed, I'd just like to mention these details to try to avoid people being misled and get disappointed as a result. Given the age and length of this bug report it may be better to open a different bug report/feature request with a more precise description of what more should be added anyway. Below is part of the description in the merge request, the last two paragraphs especially may be relevant to those who have specific needs/expectations when seeing the words "per-screen virtual desktops": > Here is a summary of the behavior (with per-output desktops enabled) from the user perspective: > > - Virtual desktops exist independently of screens. > - Each screen can show any virtual desktop (1 at a time). > - Each virtual desktop can be shown on any number of screens. > - Each window belongs to 1 screen (even if it spans multiple screens), and to any number of virtual desktops. The window is visible if its screen shows one of the virtual desktops that the window belongs to. > - Switching desktops via keyboard shortcuts (and most other methods) affects the currently active screen. > - API allows you to switch any screen to any desktop. > > Please note that the functionality implemented by this MR does NOT work like Hyprland etc, where workspaces are separate for each screen and switching to a workspace activates its screen as well. This is not because I'm not aware of the alternative behavior, but because I prefer it the way I implemented it. I'm aware that some/many people are going to be disappointed by that. But there is no one right way that is going to satisfy everyone. Had I implemented it the Hyprland way, I'd dissappoint different people. > > If you're one of the people who would prefer a Hyprland-like behavior, please keep in mind that if this MR succeeds, it doesn't mean that all is lost for you (there's no reason that KWin can't eventually support both). Not only are you no worse off than before (the current behavior of having the same desktop on all screens is supported), this MR actually implements a lot of the stuff that you'll need to implement the behavior that you want (e.g. you can't have a Hyprland-like behavior, if you can't show different desktops on different screens).
Per-screen virtual desktops means per-screen virtual desktops, and that's what we have now. It's a complex feature, and for those who'd like tweaks to the behavior, yeah, I think new Bugzilla tickets would be the best way to express those preferences. Otherwise this ticket will stay open forever, given the diversity of opinion present in the world.
Honestly, I do not think that this is a new feature or something that is preferred by a fringe population. In case of all of those who do not use multiple screens, this feature will not make a difference any way and so we should not even take them into consideration. But, when it comes to those who tend to use multiple screens, even temporarily (for instance connecting to an external screen while giving a presentation), this feature is not new at all and has been implemented in one or the other form in most tiling window managers and also in mac os. This feature vastly improves efficiency of using two screens and is the sole reason why I switched to tiling window managers in the first place. Yes, I do understand that it is slightly different in comparison to Hyprland or other tiling window managers, but that difference is easy to get used to and is much less of a hindrance in comparison to getting used to switching the workspaces on all screens at once. Kudos to Hynek Schlindenbuch for implementing this feature that has been requested a couple of decades ago.
@Nate it's been already thoroughly discussed on the MR and I am surprised to see the bug is closed. Please consider reopening. > Otherwise this ticket will stay open forever, given the diversity of opinion present in the world. There's no "diversity of opinions", the "per-screen desktop" is implemented in one exact way on *every* system that has such support, including the Awesome that the MR author was referring too — as was discussed on that MR. There is exact reason the MR was done as "CCBUG" and not "BUG" — it does not fulfill the usecase of switching between applications faster, it just adds a tiny feature which… may be useful to some people, but it's not much of a workflow improvement and… it's just a fancy, it's not something people has been asking for two decades. Please reopen the bug.
I understand from the merge request that you wanted this implemented in a different way. But that's not what we got here, and that's okay. It's not clear what the original reporter wanted, and I see from the merge request that others are fine with what we got. If you want to add an alternative implementation that uses a completely different set of desktops for each screen, that would be great! But its absence does not mean that this "Per-screen virtual desktops" has failed to be implemented.
Fair enough, the OP was indeed vague. Okay, let me create a new issue for this, I'll post a link to it here. Also, as I mentioned I am open to look into implementing the proper "per-screen desktops", but this depends on my resources, which I'm scarce on ATM, but I'll try.
(In reply to Nate Graham from comment #100) > Please reopen the bug. It is pointless to argue with Nate. He needs fancy bug close numbers for his blog. If he wants to close a bug, he will close a bug, and he closes hundreds, regardless of if it even make sense. Doesn't matter if the person who actually implemented something disagrees, doesn't matter if the owner disagrees, doesn't matter if the reporter disagrees, doesn't matter if everyone on the whole wide world disagrees, if he wants to close, he close.
Okay, created BUG-519009 @Nate: I know fixing this bug will be mentioned on "This week in KDE". If I may ask you, it would be nice if this was worded very carefully, because as you can see from reactions above, when users will see that 20 years old bug was closed, they will rejoice as first, but then when they realize it's not quite what they expected the resulting disappointment may result in frustrating comments, and it's something I am sure everyone would want to avoid. @Jean-Jacques please don't worry, I think we almost there. While writing the new report I analyzed the situation, and if everything is okay, the feature may be implemented by just adding the hotkeys on top of what was done by Hynek Schlindenbuchr — kudos for their big rework, thanks!
As I understand the feature a hotkey could be used to work around task switching being suboptimal but would not in fact meaningfully be said to impliment the feature or any version thereof. One should expect that normal workspace switching commands should do the correct thing and they never will. One should expect that clicking on ui elements won't break the metaphor but they certainly will. One should expect to be able to assign workspaces to monitors other than by kludging hotkeys but you can't. When you start of with a different metaphor you can't really get there from here in a way that will ever be satisfactory. What you do have really isn't an implementation of what anyone has on awesome or i3wm its it's own thing and its probably useful to think in terms of making it as useful as possible rather than trying to make it into i3wm. That said what about an option for workspaces to remember which monitor was focused so if you were using 1-4 on the left and 5-8 on the right monitor built in switching would work as a one step swap eg I've got left monitor on left side of ws1 and right showing right half of 5 I click super +6. 6 was last focused on right monitor so I now have 1,6 with 6 focused.
(In reply to michael from comment #104) > As I understand the feature a hotkey could be used to work around task > switching being suboptimal but would not in fact meaningfully be said to > impliment the feature or any version thereof. > > One should expect that normal workspace switching commands should do the > correct thing and they never will. > > One should expect that clicking on ui elements won't break the metaphor but > they certainly will. > > One should expect to be able to assign workspaces to monitors other than by > kludging hotkeys but you can't. > > When you start of with a different metaphor you can't really get there from > here in a way that will ever be satisfactory. > > What you do have really isn't an implementation of what anyone has on > awesome or i3wm its it's own thing and its probably useful to think in terms > of making it as useful as possible rather than trying to make it into i3wm. Well, the only thing that could possibly render wrong is the "virtual desktops" panel widget; unless I'm missing something. > That said what about an option for workspaces to remember which monitor was > focused so if you were using 1-4 on the left and 5-8 on the right monitor > built in switching would work as a one step swap eg I've got left monitor on > left side of ws1 and right showing right half of 5 I click super +6. > > 6 was last focused on right monitor so I now have 1,6 with 6 focused. Sorry, I had very hard time trying to read it (commas are missing and what is "ws1"? "workspace1"?)… My best understanding is you're asking that pressing Super+6 will focus right monitor because it's where 6 is assigned to. If that's correct, then it should be handled by the report I created.
@Konstantin sure, I'll make sure to word it carefully.
(In reply to Konstantin Kharlamov from comment #105) > (In reply to michael from comment #104) > > As I understand the feature a hotkey could be used to work around task > > switching being suboptimal but would not in fact meaningfully be said to > > impliment the feature or any version thereof. > > > > One should expect that normal workspace switching commands should do the > > correct thing and they never will. > > > > One should expect that clicking on ui elements won't break the metaphor but > > they certainly will. > > > > One should expect to be able to assign workspaces to monitors other than by > > kludging hotkeys but you can't. > > > > When you start of with a different metaphor you can't really get there from > > here in a way that will ever be satisfactory. > > > > What you do have really isn't an implementation of what anyone has on > > awesome or i3wm its it's own thing and its probably useful to think in terms > > of making it as useful as possible rather than trying to make it into i3wm. > > Well, the only thing that could possibly render wrong is the "virtual > desktops" panel widget; unless I'm missing something. > > > That said what about an option for workspaces to remember which monitor was > > focused so if you were using 1-4 on the left and 5-8 on the right monitor > > built in switching would work as a one step swap eg I've got left monitor on > > left side of ws1 and right showing right half of 5 I click super +6. > > > > 6 was last focused on right monitor so I now have 1,6 with 6 focused. > > Sorry, I had very hard time trying to read it (commas are missing and what > is "ws1"? "workspace1"?)… My best understanding is you're asking that > pressing Super+6 will focus right monitor because it's where 6 is assigned > to. If that's correct, then it should be handled by the report I created. Given this layout on i3wm [ ] is a monitor *focused* defines the monitor which has input focus at this time [ Monitor 1 displaying workspace 1 *focused* ] [ Monitor 2 displaying Workspace 5 ] User presses super + 6 with the intent to result in input focus switching to 6 on the second monitor resulting in this [ Monitor 1 displaying workspace 1 ] [ Monitor 2 displaying Workspace 6 *focused* ] One could arrive at the same thing by clicking the 6 even on the left hand screen because the system knows 6 lives on the second monitor it will never show the left hand side of 6 on the left monitor. This is also true of any event which causes 6 or its windows to be focused. If I understand the current design any of those things will always show the left side of 6 instead of showing 6 on the right monitor. The fix as I understand it is to allow a user to define a hotkey to switch to right monitor then switch to 6 so that super+6 will do the desired thing. What is wrong if anything with that. The assignment and the idea that 6 lives on monitor 2 is nowhere evident in the UI or the users configuration it lives solely in the users head and keyboard shortcuts and most be explicitly reconfigured when monitor configurations change or even when desired window configuration changes one cannot just create a workspace somewhere and use it nor move it and expect it to stay where its put because it isn't an actual useful desktop metaphor its a subset of a metaphor hacked in. The actual metaphor as implemented is that desktops span all monitors but displays can show a window on different chunks of different virtual desktops which is itself useful but its not the same metaphor.