[kwayland] Virtual Desktop protocol
Closed, ResolvedPublic

Description

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.

sitter added a subscriber: sitter.
sitter added a comment.Nov 7 2016, 2:38 PM

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.

sitter added a comment.Nov 7 2016, 2:48 PM

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

sitter added a comment.Nov 7 2016, 2:48 PM

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.

sitter added a comment.Nov 7 2016, 2:48 PM

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 dtor

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

sitter added a comment.Nov 7 2016, 2:48 PM

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

hein claimed this task.May 12 2017, 5:58 PM
hein added a subscriber: hein.

Adopting for 5.11

hein added a comment.May 12 2017, 6:00 PM

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.

jriddell updated the task description. (Show Details)Feb 12 2018, 1:44 PM
jriddell edited projects, added Plasma; removed Plasma on Wayland.
jriddell edited projects, added Plasma on Wayland; removed Plasma.Feb 12 2018, 2:29 PM
romangg triaged this task as High priority.Feb 16 2018, 10:06 PM
romangg added a project: Plasma (Plasma 5.13).
mart added a comment.Apr 24 2018, 9:57 PM

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

afaik gnome already has this, do they have some sort of protocol there?

hein added a comment.Apr 25 2018, 10:08 AM

Unlikely, Gnome's shell runs in-process with the compositor, they don't need any IPC for the same use case.

jriddell added a subscriber: jriddell.
  • Timeframe: 5.14 (target partity with X11), 5.15 activities
  • notmart and sho have a barely working version, needs activity merge thing

After D15599 the "Switch Window" containment action also needs updating to changed libtaskmanager API. That will be next.

hein added a comment.Sep 21 2018, 10:14 AM

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

mart edited projects, added Plasma; removed Plasma on Wayland.Oct 17 2018, 2:04 PM
hein added a subscriber: ngraham.EditedDec 18 2018, 8:02 AM

I'm now aware of the following remaining todos:

  • D17265 needs merging ASAP or the KCM doesn't work correctly.
  • VirtualDesktopInfo::WaylandPrivate::desktopLayoutRows() is unimplemented: The Wayland protocol doesn't tell us rows. Task for @mart.
  • The Pager on Wayland can't move Windows yet (no protocol, too). Task for KWin/KWayland general or subject to a design decision. VDG/@ngraham?
  • The KCM needs the Animation setting back (task for @hein, will come in a seperate Phab soon).
  • A small FIXME comment on line 249 of libtaskmanager/virtualdesktopinfo.cpp I'd like @mart to give me input on.
  • The window runner in KRunner also has desktops functionality, and is generally not really Wayland-fit. Task for KRunner/@broulik.

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

hein added a subscriber: broulik.Dec 18 2018, 8:03 AM
In T4457#170449, @hein wrote:
  • The Pager on Wayland can't move Windows yet (no protocol, too). Task for KWin/KWayland general or subject to a design decision. VDG/@ngraham?

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?

In T4457#170449, @hein wrote:
  • The KCM needs the Animation setting back (task for @hein, will come in a seperate Phab soon).

Thank you! :)

hein added a comment.Dec 18 2018, 5:24 PM

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.

hein added a comment.EditedJan 12 2019, 5:21 PM

We've made progress since the last TODO comment. Here's an updated one:

  • VirtualDesktopInfo::WaylandPrivate::desktopLayoutRows() is unimplemented: The Wayland protocol doesn't tell us rows. Backend implementation in the works at D17691, frontend by @hein it looks close to merge.
  • Desktop names may not be working on Wayland. See bug 403145.
  • The Pager on Wayland can't move Windows within a desktop yet (no protocol, too). Task for KWin/KWayland general or subject to a design decision that we don't want this anymore. VDG/@ngraham?
  • The window runner in KRunner also has desktops functionality, and is generally not really Wayland-fit. Task for KRunner/@broulik.
In T4457#172961, @hein wrote:
  • The Pager on Wayland can't move Windows within a desktop yet (no protocol, too). Task for KWin/KWayland general or subject to a design decision that we don't want this anymore. VDG/@ngraham?

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.

hein added a comment.Jan 12 2019, 5:56 PM

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.

hein added a comment.Jan 12 2019, 6:03 PM

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.

hein added a comment.Jan 12 2019, 6:07 PM

True enough.

zzag added a comment.Jan 12 2019, 7:46 PM
In T4457#172961, @hein wrote:
  • The Pager on Wayland can't move Windows within a desktop yet (no protocol, too). Task for KWin/KWayland general or subject to a design decision that we don't want this anymore. VDG/@ngraham?

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.

hein added a comment.Jan 16 2019, 8:36 AM

Stop-gap Plan B for delayed D17691, please help review: https://phabricator.kde.org/D18290

jriddell closed this task as Resolved.Tue, Feb 19, 10:59 AM