Bug 107302 - Per-screen virtual desktops
Summary: Per-screen virtual desktops
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Platform: Debian stable Linux
: NOR wishlist with 58 votes (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 36705 105254 115017 116883 122392 141432 224691 241839 335704 411924 424164 450991 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-06-12 23:58 UTC by Kjetil Kjernsmo
Modified: 2022-08-05 19:10 UTC (History)
57 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kjetil Kjernsmo 2005-06-12 23:58:46 UTC
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! :-)
Comment 1 Lubos Lunak 2006-02-21 10:47:09 UTC
*** Bug 122392 has been marked as a duplicate of this bug. ***
Comment 2 Lubos Lunak 2006-02-23 23:29:41 UTC
*** Bug 105254 has been marked as a duplicate of this bug. ***
Comment 3 Lubos Lunak 2006-04-28 19:12:59 UTC
*** Bug 36705 has been marked as a duplicate of this bug. ***
Comment 4 Lubos Lunak 2006-04-28 19:39:57 UTC
*** Bug 116883 has been marked as a duplicate of this bug. ***
Comment 5 Helge Hielscher 2006-04-29 14:59:18 UTC
*** This bug has been confirmed by popular vote. ***
Comment 6 Lubos Lunak 2006-08-25 14:12:21 UTC
*** Bug 115017 has been marked as a duplicate of this bug. ***
Comment 7 Kjetil Kjernsmo 2006-09-01 08:44:06 UTC
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?
Comment 8 Fergal Daly 2006-09-25 23:43:23 UTC
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.
Comment 9 Lubos Lunak 2007-02-09 13:15:32 UTC
*** Bug 141432 has been marked as a duplicate of this bug. ***
Comment 10 Grzegorz Oledzki 2007-02-19 14:14:31 UTC
Is it the same as the bug #61606 ?
Comment 11 Lubos Lunak 2008-04-22 14:46:04 UTC
#10: No.
Comment 12 Simon Yuan 2008-05-09 00:34:16 UTC
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.
Comment 13 Dennis Jansen 2008-08-14 17:31:07 UTC
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...
Comment 14 Franz Berger 2008-12-23 23:46:53 UTC
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").
Comment 15 Kjetil Kjernsmo 2009-03-09 23:49:48 UTC
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.
Comment 16 lucas 2009-03-10 04:43:55 UTC
(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.
Comment 17 lucas 2009-03-10 05:02:28 UTC
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.
Comment 18 Daniel Bausch 2009-03-10 08:27:39 UTC
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.
Comment 19 Will Stephenson 2009-12-02 09:55:25 UTC
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?
Comment 20 Martin Flöser 2009-12-02 10:32:41 UTC
(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.
Comment 21 Martin Flöser 2010-01-28 23:32:24 UTC
*** Bug 224691 has been marked as a duplicate of this bug. ***
Comment 22 Kenneth Aar 2010-02-16 23:08:59 UTC
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.
Comment 23 Martin Flöser 2010-06-15 18:58:37 UTC
*** Bug 241839 has been marked as a duplicate of this bug. ***
Comment 24 Dmitry 2010-07-10 07:56:42 UTC
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.
Comment 25 Marius Muja 2012-06-13 05:38:22 UTC
+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.
Comment 26 Marius Muja 2012-06-13 05:38:53 UTC
+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.
Comment 27 Martin Flöser 2012-06-13 07:22:43 UTC
> 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.
Comment 28 Konrad Mosoń 2013-05-17 07:03:20 UTC
What about this feature? I'm really missing it, and it's last thing I need in KDE4... will it be implemented?
Comment 29 Martin Flöser 2013-05-17 07:38:56 UTC
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.
Comment 30 Konrad Mosoń 2013-05-17 10:35:23 UTC
Bad ;(
awesomewm, xmonad and dwm can do this... so you say those WMs are bad because they break specs?
Comment 31 Martin Flöser 2013-05-17 10:54:10 UTC
(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.
Comment 32 Konrad Mosoń 2013-05-17 13:41:26 UTC
Yes, they are complaint: http://en.wikipedia.org/wiki/Comparison_of_X_window_managers (at least awesome which i use
Comment 33 Thomas Lübking 2013-05-17 15:24:27 UTC
(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????
Comment 34 Konrad Mosoń 2013-05-21 09:23:29 UTC
> Awesome is a tiling WM, KWin not

Actually, Kwin can do tiling, and Awesome can do floating...
Comment 35 Martin Flöser 2013-05-21 09:42:51 UTC
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
Comment 36 Thomas Lübking 2014-06-02 18:25:37 UTC
*** Bug 335704 has been marked as a duplicate of this bug. ***
Comment 37 Martin Flöser 2014-06-02 19:11:02 UTC
*** Bug 335704 has been marked as a duplicate of this bug. ***
Comment 38 Josep Febrer 2014-11-29 17:56:40 UTC
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
Comment 39 Josep Febrer 2014-11-29 17:57:10 UTC
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
Comment 40 Nicolas Dietrich 2016-05-25 20:42:51 UTC
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?
Comment 41 ignus.gracia+bugs.kde.org 2018-06-12 14:58:58 UTC
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.
Comment 42 Björn Feber 2019-09-14 21:21:54 UTC
*** Bug 411924 has been marked as a duplicate of this bug. ***
Comment 43 Konstantin Kharlamov 2019-10-27 12:27:36 UTC
(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?
Comment 44 Vlad Zahorodnii 2019-11-21 15:09:20 UTC
(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. :(
Comment 45 David Edmundson 2020-07-13 17:28:40 UTC
*** Bug 424164 has been marked as a duplicate of this bug. ***
Comment 46 Holger 2020-08-02 08:50:14 UTC
(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
Comment 47 Neal Gompa 2021-08-22 01:05:08 UTC
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.
Comment 48 Konstantin Kharlamov 2021-08-22 10:08:24 UTC
(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.
Comment 49 Nate Graham 2022-03-22 01:43:04 UTC
*** Bug 450991 has been marked as a duplicate of this bug. ***
Comment 50 kortrax11 2022-04-12 16:20:39 UTC
Any work being done on this?
Comment 51 Alve Svarén 2022-05-17 19:48:43 UTC
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 :)