A dedicated protocol is needed to announce the virtual desktops KWin is using and PlasmaWindow need to expose the virtual desktop.
The virtual desktop interface should not expose too much implementation detail. It should be more than a number.
A possibility might be to use a dbus interface instead of a Wayland interface.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | ngraham | T9887 Plasma 5.15 release | ||
| Resolved | hein | T4457 [kwayland] Virtual Desktop protocol | ||
| Resolved | hein | T4461 [kwin] Virtual Desktops KCM needs porting |
Originally made by graesslin at 2016-11-05 18:16:54 UTC
In KWin a slight refactoring is needed. Internally the VirtualDesktopManagement still works with numbers. For each virtual desktop a new class VirtualDesktop needs to be introduced which provides the mapping to id and to the PlasmaVirtualDesktop. Thus internally in KWin everything can continue to be number based while on Wayland it is object based.
Originally made by graesslin at 2016-11-05 17:51:29 UTC
Explaining the situation on X11:
Virtual desktops are just a number. On the root window the count of virtual desktops is announced and the number from 0 to count -1 for the current desktop. On each window a number from 0 to count -1 is exposed with -1 being the special value for on all desktops.
In addition the root window has a property with the desktop names and one with the layout.
The approach on X11 has various draw backs. The desktop is only implicitly derived from the number of desktop. Also name and position in the layout are only implicitly derived. The available protocol makes it impossible to put a window on multiple virtual desktops or to have two current desktops (e.g. per XRandr screen) at the same time.
In addition any window is allowed to change it's desktop or to change the virtual desktop. This has been a problem in the past by windows playing window manager.
The protocol we need for Wayland should not contain the problems as on X11
Originally made by graesslin at 2016-11-05 17:57:36 UTC
On Wayland we need the virtual desktop protocol to inform Plasma about the number of virtual desktops, it's layout and to switch the virtual desktop (pager). Also Plasma needs to know which window is on which virtual desktop.
Due to the experience with X11 we do not want to expose to the generic window the number of desktops and on which desktop they are. This means we want to have the virtual desktop protocol a privileged protocol.
The compositor needs to announce the virtual desktops. The way to announce "objects" server side on Wayland is through global objects. But that would allow each client to know the number of desktops. Globals are publicly announced, no restriction possible.
This makes exposing as globals impossible. A different way is to use an approach as for PlasmaWindow, but that is cumbersome by passing ids to the client and the client needs to bind an object. Nevertheless this seems the best approach.
Originally made by graesslin at 2016-11-05 18:12:23 UTC
The following protocol is proposed: org_kde_plasma_virtual_desktop_management
Events:
added(uint32_t serial)
removed(uint32_t serial)
layout(uint32_t rows, uints32_t columns)
done()Requests:
get_virtual_desktop(uint32_t serial) -> org_kde_plasma_virtual_desktop
release() -- normal dtorThe interface org_kde_plasma_virtual_desktop represents one virtual desktop. The client needs to bind it through one of the announced ids. This creates a timing gap: when the client requests it, the compositor might have removed it again. A similar problem exists in the case of PlasmaWindow. The solution there is to allow the binding of the interface, but directly send a removed event and the client should destroy afterwards.
Events:
id(string)
name(string)
layout_position(uint32_t row, uint32_t column)
activated()
deactivated()
done()
removed()Requests:
release() -- normal dtor
activate()
deactivate()PlasmaWindow interface is also changed to get new Events:
virtual_desktop_entered(org_kde_plasma_virtual_desktop)
virtual_desktop_left(org_kde_plasma_virtual_desktop)This follows the approach of Surface and Output enter/leave allowing a window to be on multiple virtual desktops. If it's no longer on any, it can be considered on all.
Originally made by graesslin at 2016-11-05 18:15:35 UTC
On Server side most of the protocol dance should be hidden. We need a Global called PlasmaVirtualDesktopManagementInterface. This allows the API user to create PlasmaVirtualDesktop (QObject). In that regard similar to PlasmaWindowManagementInterface and PlasmaWindow. Tracking the resources would be completely inside the PlasmaVirtualDesktop and not be exposed to the API user.
The typical workflow would be: API user creates a PlasmaVirtualDesktop. To remove it again it just deletes it. PlasmaWindow are entered on a PlasmaVirtualDesktop by passing a QVector<PlasmaVirtualDesktop*> to the PlasmaWindow. The tracking on which one to send enter and leave can be an implementation detail
Roman, Rohan and I had a brainstorming session on this where we stepped through the existing code in kwayland/kwin/libtaskmanager that we can use for reference, along with this ticket, and we think we have a good handle on this now. I'll start writing a skeleton and putting it in a branch and will then collaborate with Roman on fleshing it out further as his time/projects allow.
mart/plasmavirtualdesktop branch on kwayland, i started the xml file for it, I'm trying to document it as well, to see if i'm getting the protocol right
Unlikely, Gnome's shell runs in-process with the compositor, they don't need any IPC for the same use case.
Task Manager patch: https://phabricator.kde.org/D13746
Pager patch: https://phabricator.kde.org/D13748
After D15599 the "Switch Window" containment action also needs updating to changed libtaskmanager API. That will be next.
Note: The "windows" KRunner plugin needs porting to libtaskmanager as well. However, we have a problem there: KRunner is a different process, and I guess it can't bind PlasmaWindowManagement too until we figure out the privileged protocol auth stuff. KWin/KWayland maintainers?
(Removed the previous comment since it was unrelated to adding the rev.)
I'm now aware of the following remaining todos:
I think the above things are all possibly still in scope for 5.15. For 5.16 however, we should revisit the protocol with the consideration to implement the VDG design suggestions here: https://phabricator.kde.org/D14542#375522
Can they be moved from the Desktop Grid effect at least? Not being a Virtual Desktops user, I don't feel comfortable chiming in on whether it should be possible from the pager. VDG?
Thank you! :)
To clarify, it's possible to DND a window from desktop to desktop. "Can't move yet" refers to within a desktop by dragging the window a few pixels.
We've made progress since the last TODO comment. Here's an updated one:
Can't you just manipulate the windows directly when they're in the VD you're currently looking at? Using the pager to rearrange windows within an inactive VD seems like quite a niche use case. I wouldn't see this as a huge loss.
Yeah, I agree with you. The question is, should I just remove it from the X11 version so we have parity then?
I think it would be an easier pill to swallow if the feature doesn't make it into the shiny new thing that it would be for the feature to get deliberately removed from the old thing.
The pro-parity argument is mostly: Eventually I/we will stop testing X11, and X11-only features carry a maintenance burden. I'll think about it, nothing we need to solve for 5.15 though I guess.
Yeah. The pro-parity argument makes more sense once Wayland is actually usable for a majority of our users though. I think we need to get closer to that first.
I'm personally okay with not having this feature on Wayland. I don't use it pretty much, also it requires some precision to pick the correct window.
Stop-gap Plan B for delayed D17691, please help review: https://phabricator.kde.org/D18290