[Taskbar] Add option "all_workspaces"

[Anakael]

I have started to implement(research) feature show tasks only for current workspace. Feature will be controlled by option "all_workspaces": bool

[l3nkz]

Very cool. How does this work with the foreign-toplevel-manager protocol? As far as I know, there is no knowledge about workspaces.

[Anakael]

Yes, there is true. And it's problem. I planned do something like in:
#343
Information about workspaces can be obtained via IPC. Need to find way how to bind Task.id with node.id right.
Any other ideas? Maybe I miss something?

[l3nkz]

Hm, I implemented the original taskbar so that it will work on any wlroots based compositor that implements the foreign-toplevel-manager protocol. That is also the reason why the module is named wlr/taskbar. My long goal is to get support for this type of functionality (identifying the current workspace as well as knowing on which workspace the current toplevel is on) as a protocol extension into wlroots.

If you really want to use the IPC mechanism of sway for this, please make it optional for the module. For example I use the taskbar on wayfire which doesn't have such an IPC mechanism. That's also the reason why I want to get support for this into wlroots, so that this will work out of the box on many different compositors and not only on sway/wayfire …

[Anakael]

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 "workspace" entity?
Or register foreign-toplevel for each workspace? As I know workspace in sway use wl_seat for representation.

[Anakael]

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.

[l3nkz]

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 "workspace" entity?
Or register foreign-toplevel for each workspace? As I know workspace in sway use wl_seat for representation.

As I said. To support this properly, the foreign-toplevel-manager protocol needs to be extended and the compositors need to support it … That's quite some steps, hence I don't know when exactly this will happen.

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.

If the protocol gets extended this is not a problem. If you have a look in the code, you will see that we get a special handle structure for each toplevel on our system. By using this handle one can implement all these features. However not with the sway IPC. As I said, we need support for this on the wlroots protocol level.

[Anakael]

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 other WMs.
Will it be right way to implement that?
Or any other ideas?

[Anakael]

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

[l3nkz]

Yes, this is what needs to be done. Have an additional protocol for workspaces in wlroots and extend the toplevel_manager protocol to also support workspaces. At least that would be how I would try to get it accepted. If you get it accepted into wlroots, than we can enhance the compositors to support this protocol and then we can extend this module and add the wlr/workspaces ;) Buts that quite some steps …

[Anakael]

Waiting for:
swaywm/wlroots#2357
WayfireWM/wayfire#647
swaywm/sway#5597

[ammen99]

@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 client implementation.

[Anakael]

@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 client implementation.

I've start implement workspace module. I'll try to finish by end of the week.

[ammen99]

I've start implement workspace module. I'll try to finish by end of the week.

Great news! Meanwhile, I have submitted the MR herre: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40

Let's hope it is approved.

[l3nkz]

@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 client implementation.

I've start implement workspace module. I'll try to finish by end of the week.

Do I understand the protocol right that it is not yet integrated into the foreign-toplevel-manager protocol? Hence, @Anakael you implement a completely separate module for workspaces based on wlroots?

[ammen99]

The protocol is just for listing the currently focused workspace (and also all available workspaces). If this gets accepted, I'll also add the corresponding event to foreign-toplevel.