ext-workspace-v1: initial implementation by WhyNotHugo · Pull Request #9064 · swaywm/sway

WhyNotHugo · 2026-03-12T03:36:37Z

Only use a single, global group. Sway does not have any concept of workspace groups, and workspaces can move freely across outputs.

ext_workspace_handle_v1::id is never emitted; sway has no concept of ids or of stable vs temporary workspaces. Everything is ephemeral to the current session.

ext_workspace_handle_v1::coordinates is never emitted; sway does not organise workspaces into any sort of grid.

Deactivating a workspace is a no-op. This functionality doesn't really align with sway, although it could potentially be implemented to "switch to previous workspace on this output" as a follow-up.

Removing a workspace is a no-op.

Implements: #8812

WhyNotHugo · 2026-03-12T05:10:32Z

v2: use one group per output, so that clients can move workspaces to another output by moving a workspace to another group.

I haven't found a client which implements ext_workspace_handle_v1::assign, so that particular handler needs better testing.

sway/ext_workspace.c

WhyNotHugo · 2026-03-12T15:45:45Z

v3: applied suggested refactor. Squashed commits; they no make much less sense separate.

sway/tree/workspace.c

include/sway/tree/workspace.h

sway/commands/rename.c

sway/tree/workspace.c

WhyNotHugo · 2026-03-13T22:29:49Z

All concerns addressed… but apparently I've regressed and now a ext_workspace_handle_v1::activate request activates the wrong workspace. Still trying to find out how I broke this.

WhyNotHugo · 2026-03-13T22:51:11Z

There seems to now be at least one other subtle bug.

I'd mark this as draft, but the "Convert to Draft" button is broken and is a no-op.

WhyNotHugo · 2026-03-13T23:14:38Z

I debugged this further. When I say "create workspace", I mean foot && swaymsg move window to workspace 2.

If I start waybar (my ext-workspace client) early, then workspaces get id 1,2,3,4…

If I create several workspaces, and then start waybar, workspaces get ids in inverted order: 4,3,2,1.

So the first-created workspace (with sway name "1") get ids 4, the second one (with sway name "2") gets id 3, etc…

But we don't control ids, wlroots assigns them, and it seems that it doesn't assign names until the first ext-workspace client connects?

Here's the output of starting waybar before creating other workspaces:

[3853464.236] {Default Queue} wl_registry#2.global(28, "ext_workspace_manager_v1", 1)
[3853529.988] {Default Queue} wl_registry#34.global(28, "ext_workspace_manager_v1", 1)
[3853530.154] {Default Queue} wl_registry#35.global(28, "ext_workspace_manager_v1", 1)
[3853536.139] {Default Queue} wl_registry#41.global(28, "ext_workspace_manager_v1", 1)
[3853536.142] {Default Queue}  -> wl_registry#41.bind(28, "ext_workspace_manager_v1", 1, new id [unknown]#38)
[3853571.575] {Default Queue} ext_workspace_manager_v1#38.workspace_group(new id ext_workspace_group_handle_v1#4278190080)
[3853571.582] {Default Queue} ext_workspace_group_handle_v1#4278190080.capabilities(1)
[3853571.585] {Default Queue} ext_workspace_group_handle_v1#4278190080.output_enter(wl_output#21)
[3853571.587] {Default Queue} ext_workspace_manager_v1#38.workspace(new id ext_workspace_handle_v1#4278190081)
[3853571.756] {Default Queue} ext_workspace_handle_v1#4278190081.capabilities(9)
[3853571.762] {Default Queue} ext_workspace_handle_v1#4278190081.id("1")
[3853571.764] {Default Queue} ext_workspace_handle_v1#4278190081.state(1)
[3853571.765] {Default Queue} ext_workspace_group_handle_v1#4278190080.workspace_enter(ext_workspace_handle_v1#4278190081)
[3853571.766] {Default Queue} ext_workspace_manager_v1#38.done()
[3853571.773] {Default Queue} ext_workspace_manager_v1#38.done()
[3857757.947] {Default Queue} ext_workspace_manager_v1#38.done()
[3857823.645] {Default Queue} ext_workspace_manager_v1#38.workspace(new id ext_workspace_handle_v1#4278190082)
[3857823.872] {Default Queue} ext_workspace_handle_v1#4278190082.capabilities(9)
[3857823.886] {Default Queue} ext_workspace_handle_v1#4278190082.id("2")
[3857823.894] {Default Queue} ext_workspace_handle_v1#4278190082.state(0)
[3857823.900] {Default Queue} ext_workspace_group_handle_v1#4278190080.workspace_enter(ext_workspace_handle_v1#4278190082)
[3857823.911] {Default Queue} ext_workspace_manager_v1#38.done()
[3857869.321] {Default Queue} ext_workspace_manager_v1#38.done()
[3857929.178] {Default Queue} ext_workspace_manager_v1#38.workspace(new id ext_workspace_handle_v1#4278190083)
[3857929.330] {Default Queue} ext_workspace_handle_v1#4278190083.capabilities(9)
[3857929.338] {Default Queue} ext_workspace_handle_v1#4278190083.id("3")

Here's the output of creating workspaces before starting waybar:

[3913032.900] {Default Queue} wl_registry#2.global(28, "ext_workspace_manager_v1", 1)
[3913105.751] {Default Queue} wl_registry#34.global(28, "ext_workspace_manager_v1", 1)
[3913105.968] {Default Queue} wl_registry#35.global(28, "ext_workspace_manager_v1", 1)
[3913110.497] {Default Queue} wl_registry#41.global(28, "ext_workspace_manager_v1", 1)
[3913110.498] {Default Queue}  -> wl_registry#41.bind(28, "ext_workspace_manager_v1", 1, new id [unknown]#38)
[3913131.606] {Default Queue} ext_workspace_manager_v1#38.workspace_group(new id ext_workspace_group_handle_v1#4278190080)
[3913131.613] {Default Queue} ext_workspace_group_handle_v1#4278190080.capabilities(1)
[3913131.616] {Default Queue} ext_workspace_group_handle_v1#4278190080.output_enter(wl_output#21)
[3913131.622] {Default Queue} ext_workspace_manager_v1#38.workspace(new id ext_workspace_handle_v1#4278190081)
[3913131.822] {Default Queue} ext_workspace_handle_v1#4278190081.capabilities(9)
[3913131.828] {Default Queue} ext_workspace_handle_v1#4278190081.id("4")
[3913131.830] {Default Queue} ext_workspace_handle_v1#4278190081.state(0)
[3913131.832] {Default Queue} ext_workspace_group_handle_v1#4278190080.workspace_enter(ext_workspace_handle_v1#4278190081)
[3913131.834] {Default Queue} ext_workspace_manager_v1#38.workspace(new id ext_workspace_handle_v1#4278190082)
[3913131.863] {Default Queue} ext_workspace_handle_v1#4278190082.capabilities(9)
[3913131.865] {Default Queue} ext_workspace_handle_v1#4278190082.id("3")
[3913131.866] {Default Queue} ext_workspace_handle_v1#4278190082.state(0)
[3913131.868] {Default Queue} ext_workspace_group_handle_v1#4278190080.workspace_enter(ext_workspace_handle_v1#4278190082)
[3913131.869] {Default Queue} ext_workspace_manager_v1#38.workspace(new id ext_workspace_handle_v1#4278190083)
[3913131.884] {Default Queue} ext_workspace_handle_v1#4278190083.capabilities(9)
[3913131.886] {Default Queue} ext_workspace_handle_v1#4278190083.id("2")
[3913131.887] {Default Queue} ext_workspace_handle_v1#4278190083.state(0)
[3913131.888] {Default Queue} ext_workspace_group_handle_v1#4278190080.workspace_enter(ext_workspace_handle_v1#4278190083)
[3913131.889] {Default Queue} ext_workspace_manager_v1#38.workspace(new id ext_workspace_handle_v1#4278190084)

Waybar shows me widgets for both sway IPC and ext-workspace, and the mismatch is also visually obvious.

WhyNotHugo · 2026-03-13T23:24:09Z

My refactor accidentally removed the initial ext_workspace_handle_v1::name event, so sway wasn't emitting any names for workspaces.

I restored this and waybar works fine: it only uses ids if no names are supplied.

I'll report the wlroots issue properly, but it's no longer a problem for us. This is working and ready for review.

CI failures are due to API changes in wlroots.

WhyNotHugo · 2026-03-14T02:31:39Z

I'm using sway_workspace->name as id, but this property can change, and later be re-used by another workspace.

We don't have any stable id for workspaces. Maybe we can use the memory positions of the object itself?

emersion · 2026-03-14T10:22:58Z

Maybe we can use the memory positions of the object itself?

That would be unique, but may be re-used by a completely unrelated workspace later on and is not persistent across sessions.

We can leave the ID NULL instead.

WhyNotHugo · 2026-03-14T13:04:57Z

We can leave the ID NULL instead.

Done

Move workspace_move_to_output out of the command handler, so it can be re-used for ext_workspace_handle_v1::assign.

emersion

Looks good apart from these last comments!

emersion · 2026-03-14T18:55:01Z

sway/tree/workspace.c

+				}
+				name = req->create_workspace.name;
+			} else {
+				name = workspace_next_name(output->wlr_output->name);


We need to free() this after the workspace has been created.

Easiest would be to unconditionally free name, and strdup(req->create_workspace.name).

We need to strdup() in the first branch to avoid a double-free, right?

Done.

sway/tree/workspace.c

emersion · 2026-03-14T18:56:21Z

sway/tree/workspace.c

+
+// Must be called whenever an output is enabled.
+void sway_ext_workspace_output_enable(struct sway_output *output) {
+	if (!server.workspace_manager_v1 || !output->wlr_output) {


Nit: I think the !server.workspace_manager_v1 check can be removed

It can be NULL if wlr_ext_workspace_manager_v1_create fails. We simply ignore that failure at start-up (rather than bailing).

I ignored the error during initialisation because that's what similar calls do (e.g.: wlr_ext_foreign_toplevel_list_v1_create)

Maintain a 1:1 relationship between workspace groups and outputs, so that moving a workspace across groups effectively moves it across outputs. ext_workspace_handle_v1::id is never emitted; sway has no concept of ids or of stable vs temporary workspaces. Everything is ephemeral to the current session. ext_workspace_handle_v1::coordinates is never emitted; sway does not organise workspaces into any sort of grid. ext_workspace_handle_v1::assign is mostly untested, because no client current implements this. Perhaps it's best to not-advertise the feature for now? Deactivating a workspace is a no-op. This functionality doesn't really align with sway, although it could potentially be implemented to "switch to previous workspace on this output" as a follow-up. Removing a workspace is a no-op. Implements: swaywm#8812

WhyNotHugo force-pushed the ext-workspace branch 2 times, most recently from fcc4046 to ae319e5 Compare March 12, 2026 05:09

WhyNotHugo marked this pull request as ready for review March 12, 2026 05:11

emersion reviewed Mar 12, 2026

View reviewed changes

sway/ext_workspace.c Outdated Show resolved Hide resolved

WhyNotHugo force-pushed the ext-workspace branch 2 times, most recently from 3959493 to 80b723d Compare March 12, 2026 15:45

emersion reviewed Mar 12, 2026

View reviewed changes

WhyNotHugo force-pushed the ext-workspace branch from 80b723d to 9b71f7d Compare March 13, 2026 22:28

WhyNotHugo force-pushed the ext-workspace branch from 9b71f7d to ac74ec7 Compare March 13, 2026 23:18

WhyNotHugo requested a review from emersion March 13, 2026 23:24

WhyNotHugo force-pushed the ext-workspace branch from ac74ec7 to 75a4a96 Compare March 14, 2026 13:04

Make workspace_move_to_output reusable

5c30a77

Move workspace_move_to_output out of the command handler, so it can be re-used for ext_workspace_handle_v1::assign.

WhyNotHugo force-pushed the ext-workspace branch from 75a4a96 to 3532186 Compare March 14, 2026 13:05

emersion reviewed Mar 14, 2026

View reviewed changes

WhyNotHugo force-pushed the ext-workspace branch from 3532186 to b982d56 Compare March 15, 2026 01:26

WhyNotHugo requested a review from emersion March 15, 2026 01:33

Conversation

WhyNotHugo commented Mar 12, 2026

Uh oh!

WhyNotHugo commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

WhyNotHugo commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

WhyNotHugo commented Mar 13, 2026

Uh oh!

WhyNotHugo commented Mar 13, 2026

Uh oh!

WhyNotHugo commented Mar 13, 2026

Uh oh!

WhyNotHugo commented Mar 13, 2026

Uh oh!

WhyNotHugo commented Mar 14, 2026

Uh oh!

emersion commented Mar 14, 2026

Uh oh!

WhyNotHugo commented Mar 14, 2026

Uh oh!

emersion left a comment

Choose a reason for hiding this comment

Uh oh!

emersion Mar 14, 2026

Choose a reason for hiding this comment

Uh oh!

WhyNotHugo Mar 15, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

emersion Mar 14, 2026

Choose a reason for hiding this comment

Uh oh!

WhyNotHugo Mar 15, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

WhyNotHugo commented Mar 12, 2026 •

edited

Loading

WhyNotHugo commented Mar 12, 2026 •

edited

Loading