Bug 107302

*** 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. ***

*** 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 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. ***