Version: (using KDE KDE 3.3.2)
Installed from: Debian stable Packages
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 ?
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.
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.
> 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
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.
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
*** 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.
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.
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 :)