Initial implementation of cosmic-workspace-unstable-v1

[Consolatis]

I finally have decided to not wait another 3 years until the official workspace protocol is accepted. This goes very much against my own believes that labwc should only use wlroots or wayland protocols but version 1 of the cosmic-workspaces protocol is basically the same as what is proposed in the upstream protocol. Using the cosmic variant also allows using the protocol without hiding it behind feature flags as the upstream protocol may change in incompatible ways before being accepted.

This PR is an initial implementation of the protocol, mostly written in a compositor agnostic way so there is the potential to also propose this implementation for wlroots with minor changes at some point (e.g. mostly znew() vs calloc() and wl_list_append() vs wl_list_insert(x.prev, y)).

The integration part of the protocol into labwc is purposefully minimal, it only tells the client about the workspaces available, their state + name and allows the client to activate them. The protocol theoretically also allows for clients to configure the workspaces and the protocol implementation allows for that but the labwc integration does not.

Draft PR for sfwbar and Waybar to have something for testing:

• Initial implementation of cosmic-workspace-unstable-v1 LBCrion/sfwbar#212
• Add cosmic/workspaces module Alexays/Waybar#3481

Test config for Waybar

~/.config/waybar/config

    "cosmic/workspaces": {
        "format": "{name}",
        "on-click": "activate",
        "all-outputs": true,
    },

~/.config/waybar/style.css (modified the existing button:hover)

button:hover,
#workspaces button.active {
    background: inherit;
    box-shadow: inset 0 -3px #ffffff;
}

[tokyo4j]

I don't have any strong preference here since I usually use only one workspace and the integration part is minimal as you said, but what will we do when the ext-workspace-unstable is finally merged and wlroots adds implementation for it? Will we temporarily support both of cosmic-workspace-unstable-v1 and ext-workspace-unstable for compatibility? (just for question)

[Consolatis]

what will we do when the ext-workspace-unstable is finally merged and wlroots adds implementation for it? Will we temporarily support both of cosmic-workspace-unstable-v1 and ext-workspace-unstable for compatibility? (just for question)

Yes, depending on the availability of clients that would then support ext-workspaces the idea would be to support both for labwc.

[johanmalm]

Fine with me - in terms of scope. Not looked at code.
I share your verdict and had come to the same conclusion.

[Consolatis]

Waybar PR: Alexays/Waybar#3481

[01micko]

Test run, seems to work fine - screencap, is this what I'm supposed to be looking at? (methinks yes)

Back on my Slack-current install with updated latest stuff so it builds nice :)

[Consolatis]

is this what I'm supposed to be looking at? (methinks yes)

Yes, at least with the stock sfwbar.config or a derivation of it. The 1-4 on the left look like the pinned workspaces configured in the sfwbar config by default. They can be removed by commenting out the pins line in the pager section.

[01micko]

is this what I'm supposed to be looking at? (methinks yes)

Yes, at least with the stock sfwbar.config or a derivation of it. The 1-4 on the left look like the pinned workspaces configured in the sfwbar config by default. They can be removed by commenting out the pins line in the pager section.

Yeah I figured I had to use stock first up, so just renamed my user config. I'll play with it some more later.

[jlindgren90]

There is also https://wayland.app/protocols/kde-plasma-virtual-desktop - not sure of the pros/cons of following Cosmic vs. KDE here.

[droc12345]

The only comment I have about adding different implementations like these is
to try and keep it so that it can be easily removed, if need be.

[stefonarch]

There is also https://wayland.app/protocols/kde-plasma-virtual-desktop - not sure of the pros/cons of following Cosmic vs. KDE here.

The lxqt-panel will use this one if the compositor is kwin_wayland. Desktop pager and "Move to Desktop x" in the windows button right click menu of the taskbar are working fine with it.

[Consolatis]

There is also https://wayland.app/protocols/kde-plasma-virtual-desktop - not sure of the pros/cons of following Cosmic vs. KDE here.

From a quick look:

• The cosmic variant is an older version of the protocol submitted at wayland-protocols and should be easy to adjust to the official one once merged
• The KDE one looks completely independent and I am not aware of any upstream efforts.
• The KDE one is also way less flexible. E.g. it doesn't seem to notify about any output <--> workspace relation, doesn't allow the compositor to send independent workspaces per output nor allow a client to change the workspaces on a defined output. It also doesn't provide any form of capability systems so a panel can't disable options not supported by the compositor.
• The upstream / cosmic variant allows for output independent workspaces via the group concept and has a capability system.
• Additionally the upstream / cosmic one also supports slightly different concepts for workspaces like tags (globally or per output) as multiple workspaces can be active at the same time.

[jlindgren90]

If the cosmic protocol is closer than the upstream MR, then that's reason enough, you've convinced me :)

My only other thought: there was a wlr protocol proposed 5(!) years ago, https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/35. It was closed in favor of the upstream wayland-protocols MR, and there's been no discussion on it recently. Would it be worth checking with the wlroots folks if it could be revived, given that the upstream MR seems to have stalled?

I do realize wlroots development also happens slowly... if there is no interest there, then I'm fine with adopting the cosmic namespace variant. But it might be worth at least asking.

[Consolatis]

My only other thought: there was a wlr protocol proposed 5(!) years ago, https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/35. It was closed in favor of the upstream wayland-protocols MR, and there's been no discussion on it recently. Would it be worth checking with the wlroots folks if it could be revived, given that the upstream MR seems to have stalled?

That is an even older variant of the current upstream MR (and thus also an older version of the cosmic vendored one). I don't think we want yet another version of the same protocol floating around. My hope is that either the upstream one is merged within the next year or if that is not the case that wlroots will accept an implementation of the cosmic variant instead (for example the protocol implemenation in this PR that could be slightly adapted for wlroots). In the meantime, compositors and panels can add support for the cosmic vendored one which can be very easily adapted for the upstream MR once merged (as of now I think it only replaced the wl_array capabilities with a proper single uint32_t bitset).

I do realize wlroots development also happens slowly... if there is no interest there, then I'm fine with adopting the cosmic namespace variant. But it might be worth at least asking.

As both cosmic and wlroots are members of the wayland-protocols governance body and protocols in the ext- namespace only need 2 ACKS from members I do not think that wlroots would accept a new wlr vendored protocol. At that point it would make way more sense to get the upstream one merged. See also https://gitlab.freedesktop.org/wlroots/wlr-protocols#submitting-new-protocols.

[jlindgren90]

My hope is that either the upstream one is merged within the next year or if that is not the case that wlroots will accept an implementation of the cosmic variant instead (e.g. for example this one that could be slightly adopted for wlroots).

Okay, this makes sense... a wlroots implementation would continue to use the "cosmic-" protocol namespace then (until the "ext-" version is merged). I am good with this approach.

[johanmalm]

Have left a bunch of review comments - but other than those it LGTM. Not tested.

A couple of general points:

• Should we prefix with wlr_cosmic_? Couldn't we just do cosmic. For example wlr_cosmic_workspace_group_output_enter()
• We ought to consider ways to not lose created workspace on Reconfigure. Can do that on separate PR though if we can think of something.

[johanmalm]

Should this TODO still be here?

[Consolatis]

Will work on the remaining items tomorrow and then remove the TODO but none of them should cause any issues.

[Consolatis]

Have left a bunch of review comments - but other than those it LGTM. Not tested.

Thanks.

• Should we prefix with wlr_cosmic_? Couldn't we just do cosmic. For example wlr_cosmic_workspace_group_output_enter()

I've changed everything to a lab_cosmic_ prefix, the wlr_ one was intended to upstream the protocol implementation at some point but that is really easy to fix with some sed 's/lab_cosmic/wlr_cosmic/g'.

• We ought to consider ways to not lose created workspace on Reconfigure. Can do that on separate PR though if we can think of something.

I've removed the feature for clients to create workspaces completely as its unclear who is in control of the final workspace configuration. We could consider adding that back at some point (it just requires reacting to two signals).

[johanmalm]

This is indeed a nice wrapper. I now get it 😄

Suggest that we avoid assert() and just exit() with an error message.

Suggest that we call it array_add() becase:

1. xwl makes me think of XWayland
2. It actually does more than wl_array_add() + die-on-null

Also suggest adding the following to the comment in the header to make it easier to wrap one's head around it:

Let us illustrate the function of this macro by an example:

    uint32_t value = 5;
    array_add(array, value);

...is the equivalent of the code below which is how you would
otherwise use the wl_array API:

    uint32_t *elm = wl_array_add(array, sizeof(uint32_t));
    if (!elm) {
    	perror("failed to allocate memory");
    	exit(EXIT_FAILURE);
    }
    *elm = value;

[Consolatis]

Renamed to array_add(), replaced the assert with exit() and added your comment.

[johanmalm]

Have tested with waybar. Works well.

LGTM other than the suggestion I just left on the array-macro.

[g7fya]

hello, installed labwc and sfwbar from Consolatis repositorie, work great. However, is there a way where sfwbar taskbar to show only windows from the current workspace?

[Consolatis]

is there a way where sfwbar taskbar to show only windows from the current workspace?

No, that requires a further protocol to match windows with workspaces. This one only supports controlling the workspaces themselves.

[LBCrion]

No, that requires a further protocol to match windows with workspaces. This one only supports controlling the workspaces themselves.

We could implement cosmic-toplevel-info-unstable and cosmic-toplevel-management-unstable with a fallback to wlr-foreign-top-level in theory. Although I suspect that's out of scope for now ;)

[Consolatis]

No, that requires a further protocol to match windows with workspaces. This one only supports controlling the workspaces themselves.

We could implement cosmic-toplevel-info-unstable and cosmic-toplevel-management-unstable with a fallback to wlr-foreign-top-level in theory. Although I suspect that's out of scope for now ;)

Kind of, it also becomes really messy once (and if) the upstream protocols are merged. Then we'd have

• wlr-foreign-toplevel
• ext-foreign-toplevel-list
• ext-foreign-toplevel-info
• ext-foreign-toplevel-management
• cosmic-foreign-toplevel-info
• cosmic-foreign-toplevel-management

I am already quite happy when we can finally switch workspaces via panel (and have an indicator of the active workspace).

[LBCrion]

Don't forget the yet-to-be-named ext protocols for toplevel-workspace interaction (probably two of them as well? Info and management), since ext-topvel-* and ext-workspace are currently completely unaware of each other and the plan it to have bridging protocols linking them.

…

On Thu, 8 Aug 2024, 20:29 Consolatis, ***@***.***> wrote: No, that requires a further protocol to match windows with workspaces. This one only supports controlling the workspaces themselves. We could implement cosmic-toplevel-info-unstable and cosmic-toplevel-management-unstable with a fallback to wlr-foreign-top-level in theory. Although I suspect that's out of scope for now ;) Kind of, it also becomes really messy once (and if) the upstream protocols are merged. Then we'd have - wlr-foreign-toplevel - ext-foreign-toplevel-list - ext-foreign-toplevel-info - ext-foreign-toplevel-management - cosmic-foreign-toplevel-info - cosmic-foreign-toplevel-management I am already quite happy when we can finally switch workspaces via panel. — Reply to this email directly, view it on GitHub <#2030 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASHPFFHLNRSTKQ2RUVHV5ODZQO2H7AVCNFSM6AAAAABLPS3Q4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZWGQZDAOJSG4> . You are receiving this because you commented.Message ID: ***@***.***>

[Conan-Kudo]

There is also https://wayland.app/protocols/kde-plasma-virtual-desktop - not sure of the pros/cons of following Cosmic vs. KDE here.

The lxqt-panel will use this one if the compositor is kwin_wayland. Desktop pager and "Move to Desktop x" in the windows button right click menu of the taskbar are working fine with it.

I don't know this for sure, I think @Zamundaaa would know for sure, but I think the goal is to support ext-workspace in KWin.

[Zamundaaa]

I think the goal is to support ext-workspace in KWin.

At some point, yes.

[johanmalm]

LGTM

[01micko]

Wow! Excellent!