Anakael

Yes, there is true. And it's problem. I planned do something like in: https://github.com/Alexays/Waybar/pull/343 Information about workspaces can be obtained via IPC. Need to find way how to bind `Task.id`...

I don't really want to bound with IPC too. But not found way how to do it with foreign-toplevel. So what way to do it correctly? Write another protocol for...

Another problem: what unique id for app in foreign-toplevel? app_id is not unique. It required for case when have 2 Alacrity instance, for example and move one to another workspace.

How about writing something like toplevel_manager, but for workspace and extend toplevel_manager to pass new entity "workspace" with handler? In this case sway/workspace also can be replaced with wlr/workspaces for...

If this idea is good - let me know and I'll try to write such protocols and maybe some UMLs.

Waiting for: https://github.com/swaywm/wlroots/pull/2357 https://github.com/WayfireWM/wayfire/pull/647 https://github.com/swaywm/sway/pull/5597

> @Anakael Do you have an implementation for Waybar already? It would be needed eventually for merging the protocol into wayland-protocols, because the requirement is to have at least one...

https://github.com/Anakael/Waybar/tree/workspace-manager-implementation branch for tracking implementation

> https://github.com/Anakael/Waybar/tree/workspace-manager-implementation > branch for tracking implementation I really don't mess high-level WorkspaceManager with wlr C code. Any ideas how to separate them?

> No, that's the ugly life of a C++ programmer working with C interfaces. What you did is basically what I usually also do. Have some very small static C-style...