Virtual desktop protocol

[acrisci]

Nearly every window manager has a concept of a "virtual desktop" in their operation.

i3 has the concept of "workspaces" and Awesome has "tags" which are nearly identical concepts. Each output has a currently active workspace that has its own set of visible windows, and inactive workspaces that are hidden. Many workspaces can exist on an output and each output has its own set of workspaces. Outputs can switch workspaces independently of each other.

Xfce and Gnome have "virtual desktops". There is a single set of virtual desktops for the whole screen. This nomenclature comes from the _NET_DESKTOP_* EWMH root window properties and client requests.

I would like to support both paradigms if possible.

The goal of this protocol is to support out of process bars that can be run on any window manager. This was never possible on X11 because EWMH only supported the "virtual desktop" paradigm.

Required of the protocol:

List all of the workspaces for each output.

This is to display the workspaces on the bar and their active status.

A way to request a change in the active workspace or a create a new workspace

A bar might request this when the user interacts with the bar like clicking a button. The compositor should be able to deny the request.

Workspaces on multiple outputs at once

This is to support the traditional virtual desktop paradigm. This might require desktop status to be double buffered to support changing workspaces on several outputs at once.

The first target compositors are sway and way-cooler.

Let me know if you have concerns. If you like the idea, I'll write some XML.

[ddevault]

My gut reaction to this protocol is to be cautiously optimistic, emphasis on cautiously. I think a good protocol for this may be hard to write.

Workspaces on multiple outputs at once

I'm not sure that it makes sense for the sake of GNOME-like paradigms to make workspaces always a child of an output. Even sway may eventually provide config knobs to change its behavior in this way (you can already hack it together). We should make workspaces a standalone concept that can optionally have any number of outputs associated with them.

A way to request a change in the active workspace or a create a new workspace

Change, yes. Create, not so sure.

We should also consider the possibility of one output having several visible/active outputs. Swaybar also needs to be able to distinguish between hidden, visible, focused, and focus-inactive workspaces.

[acrisci]

I think a good protocol for this may be hard to write.

Absolutely. But the benefit would be great. I think we all want to have modular desktops where we can choose the components that work best for us. We never had a thriving bar ecosystem on X11 so I'm motivated to give it a shot.

We should make workspaces a standalone concept that can optionally have any number of outputs associated with them.

This is a good idea. I don't want to prescribe any design for compositor workspace functionality. Maybe a many-to-many relationship between workspaces and outputs would be flexible enough to accommodate whatever people may think of.

hidden, visible, focused, and focus-inactive workspaces.

Yeah, maybe make these properties of the desktop. We can bump the protocol if someone thinks of something new and not everybody needs to support everything. Focus-inactive workspace is derived from the focus order though I think.

[Ongy]

Many workspaces can exist on an output and each output has its own set of workspaces. This isn't exactly true in waymonad either. Workspaces are a "global" thing that can be displayed on any output. So I agree, that the binding to an output wouldn't be optimal.

We also have another distinction: empty/non-empty. Iirc swaybar/i3bar will not have buttons for empty workspaces by default. Should those be advertised?

And what would be the semantics of "create", switch to a formerly empty, but existing workspace, or create a completly new workspace? IMO the former case should be supported, the second one might be a good case for an optional interface that may or may not be advertised by the compositor on bind.

[ddevault]

Iirc swaybar/i3bar will not have buttons for empty workspaces by default.

Sway destroys empty workspaces but I acknowledge the need for this feature

[Timidger]

i3 has the concept of "workspaces" and Awesome has "tags" which are nearly identical concepts.

Just to clarify one point: workspaces are a subset of tags. A client can exist on multiple tags, but a client can not exist on multiple workspaces. This shouldn't affect this proposal though.

I like the idea. If you want a reference implementation in Way Cooler though it will have to wait at least until after exams (which are in two weeks from now) and after I put in enough work to get tags (and keybindings...) working in Way Cooler.

[acrisci]

Btw, if anyone wants to take this up, go ahead. I have other wlr projects going on I can work on.

[ddevault]

KDE discussion on this matter https://phabricator.kde.org/T4457#64699

[chrisjbillington]

Somewhat resuming the conversation on grids from the pull request thread, I think re-introducing the idea of "workspace groups" as I originally put in the pull request (but removed as not strictly necessary) might be a good idea, and might make some things much clearer about how a protocol can map to the various concepts in the different compositors that we would like to cover.

So, here are some definitions that I am hoping cover as much as possible, including the concept of "workspace groups".

• workspace: a subset of the surfaces that belong to a particular set of outputs. Surfaces may belong to any number of workspaces, but they can only belong to a given workspace if they are on one of the outputs assigned to it. The reason for outputs being involved at all is described in the definition of a workspace group, below, which helps accommodate the two paradigms for interaction of workspaces and outputs that exist presently.

• workspace group a set of workspaces, that have identical sets of outputs assigned to them. Although this concept is not strictly necessary in the protocol (which workspaces share outputs could be computed by the client by doing set arithmetic on the total set of workspaces and the outputs assigned to them), I think it is useful to have it anyway, as it clarifies some concepts. Hopefully this will become clear. If the idea of a workspace group is included in the protocol, then rather than assigning workspaces to outputs, the protocol would assign a workspace group to some set of outputs, and the workspace group would then contain workspaces. The usefulness of grouping outputs like this, and of assigning outputs to workspace groups at all, is to support both paradigms of each individual output having its own set of workspaces, and of all outputs sharing workspaces. In the former case, each workspace group would be assigned to a single output, and there would be as many workspace groups as outputs. In the latter case, there would be a single workspace group assigned to all outputs. Arbitrary other groupings of workspaces would also be allowed by the protocol, so you might have something like the following:

But there is no reason to preclude the same output being in multiple workspace groups, either. And, there is no reason to prevent two workspace groups having identical sets of outputs. This is the only strict difference from not having workspace groups at all: without explicit workspace groups in the protocol, the client can only infer them by which workspaces have identical sets of outputs assigned to them, and so 'different workspace groups but with the same outputs' would not be possible. While I like workspace groups existing explicitly because it makes things much clearer, it also means that workspace groups have identity distinct from the set of outputs they are attached to, which makes them more flexible. Flexible for what? Who knows!

• active/inactive. Workspaces can be 'active' or 'inactive', with the exact meaning being compositor-dependent, but conceptually with 'inactive' implying some kind of de-emphasis or hiding of those surfaces, and 'active' implying the surfaces should be shown as normal. Multiple workspaces can be active at once, even on something like gnome-shell: it only allows one active workspace per workspace group. But other compositors may allow multiple active workspaces per group, for example these tags I keep hearing about and should read up on.

• coordinates. Workspaces might be conceptually arranged by a compositor in one or more N-dimensional grids, in which case each workspace has a coordinate within one of the grids. The compositor might not have such a concept though, in which case it could just not send the events pertaining to coordinates. These grids benefit from the workspace group concept, because each workspace group can have its own grid: i.e. there is no global grid of workspaces. Workspaces must have unique coordinates within their workspace group only. This accommodates both of the two paradigms for grids that there are. In gnome-shell for example (well, once you enable an extension that makes the workspace grid 2D), there is one grid per output, i.e. one grid per workspace group (though gnome-shell can also be configured to have workspaces span all otuputs, in which case there is only one workspace group and hence only one grid).

Other than uniqueness within a workspace group, that each dimension's index is a uint32, and a comment that the coordinates are by convention to be treated as representing [x, y, z,...] coordinates for the purpose of the client representing them graphically, there is no restriction on them, they need not be contiguous or bounded or anything. I think this is adequate for both gnome-shell and wayfire at least, and may not be relevant for others, but it is optional so they can just skip it.

A question: Should compositors that wish to number workspaces without the geometric interpretation use 1D coordinates? Or should workspaces additionally have a number? Because as written so far, using 1D coordinates implies a horizontal geometric interpretation, and whilst we could argue that in 1D geometry is undefined, what then should a compositor send if it does want a horizontal geometric interpretation? My preferred answer: define 1D coordinates as having no geometric interpretation and simply being numbers, and compositors that wish to have a certain geometry for a 1D list of workspaces can send 2D coordinates with a constant x or y coordinate. There's been some discussion around this in the pull request thread, but I think my suggestion is a good solution: you need 2D before 'horizontal' or 'vertical' are meaningful, so compositors can send that if they care, otherwise they are not implying any geometry. So the comment about the convention would need to say that the geometric interpretation only applies for 2D and greater.

• name Each workspace has a string name. Names don't have to be unique. These can be used as tags.

I'm interested in which workspacey paradigms exist in compositors that are not covered by this. I think it matches what I know of GNOME and KDE, and I'm pretty sure it matches Wayfire if wayfire works the same way as compiz does with workspaces. I am less familiar with the tagging, so if the name property is insufficient for this, let's talk about that.

[ammen99]

Despite being initially confused by the notion of workspace groups, I now see that they simplify the problem. So +1 from me.

[chrisjbillington]

Swaybar also needs to be able to distinguish between hidden, visible, focused, and focus-inactive workspaces.

Looks like it also would want to know about 'urgent' workspaces. If the foreign-toplevel-management protocol grows workspace_enter and workspace_leave events and a urgent status, then you could use those to infer focused and urgent workspaces, based on whether workspaces contain toplevels with an active or urgent state. Would that be sufficient?

[Anakael]

Any updates here? I would like to participate!

[chrisjbillington]

Hi @Anakael, there is a requested change in my pull request here yet to be made. If you are interested in in implementing that change I'd be happy to give you push access to the fork the PR is coming from. Let me know! Otherwise, I've said I would make that change but I haven't gotten around to it yet.

That's the only outstanding work on the protocol I'm aware of, otherwise I think we are waiting for someone interested to implement the protocol in a compositor as a test to see if it makes sense.

edit: There is also this comment from @ammen99 proposing some changes

[ammen99]

I have started to implement the protocol here: https://github.com/ammen99/wlroots/tree/wlr-workspaces

It contains several fixes to the protocol, and of course a lot of the code needed in wlroots. I plan to finish the wlroots part this week, and then I have to do:

1. wlroots example client
2. Wire up a compositor to test (probably Wayfire because that's what I'm familiar with)
3. Rename protocol to ext namespace and submit to wayland-protocols (assuming @chrisjbillington doesn't want to continue with this part)

I am also not sure what the rules for inclusion in wayland-protocols are, iirc we may need a few more clients and compositors which have support for the protocol for it to be merged.

[emersion]

we may need a few more clients and compositors which have support for the protocol for it to be merged.

Depends what the namespace is. For the ext namespace only a single client and compositor implementation is required, so the requirements are not higher. Though, I don't think a dummy example client is enough, we'll need a real-world client.

[Anakael]

@ammen99 Can I contact you to ask some questions how foreign toplevel manager works?

[ammen99]

@Anakael yes, feel free to ask me questions. Do you have IRC? You can find me at #sway-devel (or #wayfire)

[Anakael]

So, "move" workspace logic can be made by "remove" + "add"?

[ammen99]

Yes, that's how it can be done.

[werererer]

@ammen99 does it already work? If yes I'd really like to implement such a protocol into my compositor.

[ammen99]

@ammen99 does it already work? If yes I'd really like to implement such a protocol into my compositor.

I have open pull requests: https://github.com/swaywm/wlroots/pull/2357 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40

I hope there won't be many changes requested in reviews, but I am basically waiting for a thorough review to move forward with final renaming.

[werererer]

ok i'll wait then until it is merged

[emersion]

wlr-protocols has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/10