Virtual Desktops for Plasma 6
This is sort of part of the Activities discussions, but because it's a pretty large topic without them as well I split out this issue for VDs.
Status Quo
There's a grid of n * m virtual desktops. These VDs are static, cover all outputs and are the same in all Activities. When you switch VDs, all windows on all monitors switch VDs. When you switch Activities, by default it stays in the same virtual desktop position or optionally switches you to the last VD used in the switched-to Activity.
Use cases
I think these are the two high level use cases we have to take care of:
- permanent spatial separation of smaller tasks or applications. An example for this would be that you always put the music player on a specific VD, the IDE on a different one etc
- providing more space to work with, but without any persistent task association. Effectively VDs are additional monitors for this use case
I'll call these (1) static and (2) dynamic setups from here on.
Multi Monitor
There's two options in regards to multi monitor:
- All monitors are on the same VD. Switching VDs will move the state on all monitors
- All monitors have a separate list of VDs. Both options to switch only on one monitor and on all monitors at once can be provided
Activities
Generally it makes sense for both static and dynamic setups for VDs to be completely separate per Activity.
Ideally, the dynamic/static state would also be per Activity, but if it makes the implementation simpler I think it wouldn't be a large loss to make it be the same in all Activities. Same for multi monitor options; it's probably not necessary to support a different setting per Activity.
What to (not) support
In order to limit the complexity of both implementation and UX, a line has to be drawn somewhere. I think we can simplify these things:
- static setups + per monitor VD layouts. Static setups should be required to have the same amount of VDs per monitor, so that we have a clear and intuitive mapping of what should happen when you unplug a monitor with windows still on it (-> move into the matching VD on the other monitor)
- dynamic setups + VD grids. While not impossible, grids do make the UX more complex, especially if VDs are automatically added and removed. So I think we should just not support that
- naming VDs in dynamic setups. Names create the illusion that VDs would be somehow permanent when they're not, so that should not be supported either.
- sharing VDs between Activities. With Activities being explicit separation between environments, sharing VDs doesn't make any sense and should not be supported
- apps interacting with VDs. The usefulness is questionable and creates very different API requirements, so keeping access restricted to plasmashell in the new implementation would be sensible
How to get there
In order for KWin internals to change, the outward facing APIs must also change; that's what more or less requires such a change to happen with the Plasma 6 transition. The APIs to change would be:
- Wayland: https://invent.kde.org/libraries/plasma-wayland-protocols/-/blob/master/src/protocols/plasma-virtual-desktop.xml, can be easily extended. Adopting https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40 would also be in the cards, it supports pretty much everything we need
- X11: https://invent.kde.org/frameworks/kwindowsystem/-/blob/master/src/platforms/xcb/netwm.h, need to create new API for that
- also dbus for some reason? https://invent.kde.org/plasma/kwin/-/blob/master/src/virtualdesktopsdbustypes.cpp
- Effects and scripting
I haven't started properly looking into any implementations yet, but if we need to break backwards compatibility with other X11 DEs anyways, we could directly switch to a dbus protocol or sth that can be used on both Wayland and X11