Implement ext-workspace

[YaLTeR]

Implements #135.

TODO:

• ~~ext_workspace_manager_v1::commit() request (currently changes are applied right away)~~
• ~~we need to match by manager object when sending events, not by client~~

Also, apparently the two existing clients (sfwbar and xfce4-panel) are quite broken? Will need to fix them before I can merge this into niri.

sfwbar: :white_check_mark:

• ~~crashes because missing handler for ext_workspace_handle_v1::id(). For now you can comment out the two calls to .id() in niri~~
• ~~doesn't handle atomic name updates and/or duplicate names properly~~
• ~~doesn't handle groups. Puts all workspace groups into one list which breaks for example the Active state~~

xfce4-panel:

• ext_workspace_handle_v1::id() prints a critical: g_object_set_is_valid_property: property 'id' of object class 'XfwWorkspaceWayland' is not writable
• freaks out with multiple workspace groups (i.e. two monitors): only shows one monitor's workspaces, stops highlighting the active workspace, I also saw it prevent some workspace switching and eventually crash

waybar https://github.com/Alexays/Waybar/pull/4016: :white_check_mark:

• ~~only seems to show the primary output workspaces~~

quickshell: impl in progress

Apart from this, would be nice to add some client-server tests I guess.

cc @outfoxxed for quickshell

[YaLTeR]

Also cc @stefonarch for LXQt

[Consolatis]

Also, apparently the two existing clients (sfwbar and xfce4-panel)

There is also https://github.com/Alexays/Waybar/pull/4016

[YaLTeR]

Thanks, tested that PR. For anyone else, suggested config:

    "wlr/workspaces": {
        "sort-by-name": false,
        "sort-by-coordinates": true,
        "on-click": "activate"
    },

[outfoxxed]

I'll fast track the Quickshell impl, might be ready for testing before this is merged, might not.

[Consolatis]

xfce4-panel:

• ext_workspace_handle_v1::id() prints a critical: g_object_set_is_valid_property: property 'id' of object class 'XfwWorkspaceWayland' is not writable
• really freaks out with multiple workspace groups (i.e. two monitors): doesn't show all workspaces, prevents some workspace switching, eventually crashes

I didn't find an issue for this at xfce4-panel or libxfce4windowing so JFYI @Tamaranch

[YaLTeR]

Fixed a few things; I believe this should be good to go on the niri side. Would be good to get more testing though.

[ogios]

So currently we lack way to tell which active workspace we are focusing, typically when we got multiple monitor setup, can urgent state be applied to that? or is it not a concern?

[YaLTeR]

Urgent is for urgency though (when a workspace has an urgent window). So yeah there's no way in ext-workspace to tell which monitor is focused. This is not a concern for niri; it might be a concern for the protocol though, or maybe other protocols can be used instead.

[outfoxxed]

The activate() capability is available but doesn't seem to actually do anything when sent. Also you should probably unset the activate capability for the workspace you're currently on.

Additionally, I've used set-workspace-name to name a workspace at runtime. It seems like you should be able to remove() a workspace with a name set that way, if it has no toplevels. (Or if it does, and move them somewhere else.) I wouldn't allow removal of workspaces created with workspace "name" in the config though.

Incomplete work on the qs side you can test with: https://github.com/quickshell-mirror/quickshell/tree/wip-ext-workspace

Tester here: https://github.com/quickshell-mirror/quickshell/blob/wip-ext-workspace/src/windowmanager/test/manual/workspaces.qml

[YaLTeR]

The activate() capability is available but doesn't seem to actually do anything when sent.

Not forgetting to send commit() afterward?

Also you should probably unset the activate capability for the workspace you're currently on.

Is that needed/expected? What do others do?

Additionally, I've used set-workspace-name to name a workspace at runtime. It seems like you should be able to remove() a workspace with a name set that way, if it has no toplevels. (Or if it does, and move them somewhere else.)

Hmm, I can see your point here, but also it feels a bit weird. That said I'm not sure how people actually use runtime workspace naming, I personally only use statically-configured workspaces.

You can also unset name of a configured workspace, then set it or some other to the same name again which somewhat blurs the line between the two. Config reloading will just create all workspaces declared in the config if they don't exist at the point of reloading.

Incomplete work on the qs side you can test with: https://github.com/quickshell-mirror/quickshell/tree/wip-ext-workspace

Tester here: https://github.com/quickshell-mirror/quickshell/blob/wip-ext-workspace/src/windowmanager/test/manual/workspaces.qml

Thanks, will try.

[outfoxxed]

Not forgetting to send commit() afterward?

Yep. Works with commit. (pushed fix)

Is that needed/expected? What do others do?

I'm not sure, its not specified anywhere but I would think since activating a workspace you're currently on does nothing it shouldn't be available. I don't think it will have much of an impact either way.

Hmm, I can see your point here, but also it feels a bit weird. That said I'm not sure how people actually use runtime workspace naming, I personally only use statically-configured workspaces.

You can also unset name of a configured workspace, then set it or some other to the same name again which somewhat blurs the line between the two. Config reloading will just create all workspaces declared in the config if they don't exist at the point of reloading.

If they're functionally equivalent it would make sense to be able to remove all of them, since its a logical operation via IPC.

[YaLTeR]

sfwbar fixed all outstanding ext-workspace issues!

[Consolatis]

Also you should probably unset the activate capability for the workspace you're currently on.

Is that needed/expected? What do others do?

I don't think any implementation changes the capabilities at runtime. As for this specific case the protocol states

There is no guarantee the workspace will be actually activated

So the compositor simply ignoring that event in this case seems sufficient.

[outfoxxed]

I don't think any implementation changes the capabilities at runtime. As for this specific case the protocol states

It does state that, and by the protocol both ways are definitely correct.

I think it might just be more helpful if as much useful information that can be encoded in the protocol was encoded in it. The activate capability being present indicates that it probably does something.

[stefonarch]

Just to confirm that it works all fine with my dual monitor setup and sfwbar (but it seems that xfce4-panels pager can't handle 2 monitors).

[Tamaranch]

xfce4-panel:

• ext_workspace_handle_v1::id() prints a critical: g_object_set_is_valid_property: property 'id' of object class 'XfwWorkspaceWayland' is not writable
• really freaks out with multiple workspace groups (i.e. two monitors): doesn't show all workspaces, prevents some workspace switching, eventually crashes

I didn't find an issue for this at xfce4-panel or libxfce4windowing so JFYI @Tamaranch

Thank you, the id thing should be fixed by https://gitlab.xfce.org/xfce/libxfce4windowing/-/merge_requests/80; for the workspace groups I opened https://gitlab.xfce.org/xfce/libxfce4windowing/-/issues/47: to be investigated…

[Tamaranch]

@YaLTeR I built your branch locally to reproduce the problems listed above with xfce4-panel. Could you (or anyone else who knows) give me an example configuration for having multiple workspace groups?

[outfoxxed]

Could you (or anyone else who knows) give me an example configuration for having multiple workspace groups?

Have multiple monitors

[Tamaranch]

Could you (or anyone else who knows) give me an example configuration for having multiple workspace groups?

Have multiple monitors

Ah ok, thanks. I have two monitors, but the laptop is disabled by default for some reason, I'll check that.

[Tamaranch]

Could you (or anyone else who knows) give me an example configuration for having multiple workspace groups?

Have multiple monitors

Ah ok, thanks. I have two monitors, but the laptop is disabled by default for some reason, I'll check that.

It was because the laptop lid was closed. I do have two active monitors now, but still only one group of workspaces as far as I can see. Or maybe the panel only uses one and I can't reproduce the bugs above... I'll trace this later to be sure.

EDIT: Ok I do have two groups in fact, and it's indeed buggy (since the panel only takes the first one into account), however I can't reproduce the behaviors listed above (warnings, crashes, etc.). I'll continue my tests later and let you know when it's fixed.

[Tamaranch]

Problems with xfce4-panel should now be fixed by the above commits, testing appreciated. You will need to build xfce4-panel and libxfce4windowing from git master/main (not sure when the next releases will be, especially for libxfce4windowing...)

[YaLTeR]

Thanks for fixes and testing! I'll give it a go too. This PR should be good to merge then

[YaLTeR]

@Tamaranch gave xfce4-panel a go; seems to work fine across two monitors with two panels assigned to each. Only thing is, would be good to have an option to sort by ext-workspace coordinates.

[YaLTeR]

Alright thanks everyone for testing and fixing the respective desktop components. Let's continue on main

[Tamaranch]

@Tamaranch gave xfce4-panel a go; seems to work fine across two monitors with two panels assigned to each. Only thing is, would be good to have an option to sort by ext-workspace coordinates.

This one is more of a feature request. I'm going to open it on our gitlab, but I don't know when it will be addressed.

EDIT: See https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/938