Waybar
Waybar copied to clipboard
Alexays
[Taskbar] Add option "all_workspaces"
I have started to implement(research) feature show tasks only for current workspace. Feature will be controlled by option "all_workspaces": bool
Very cool. How does this work with the foreign-toplevel-manager protocol? As far as I know, there is no knowledge about workspaces.
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 with node.id right.
Any other ideas? Maybe I miss something?
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 …
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.
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.
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.
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?
If this idea is good - let me know and I'll try to write such protocols and maybe some UMLs.
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 …
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 client implementation.
@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.
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.
@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?
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.
Ok, than I understood it correctly. Great work @ammen99. Thank you very much for your effort!
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 functions that are used as callbacks for the C interface. These C-style functions only do one thing, call the proper C++ member function.
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 functions that are used as callbacks for the C interface. These C-style functions only do one thing, call the proper C++ member function.
Yeah, but there are (about FTM) half of file such small functions and bindings and it's become harder to read high-level taskbar API. I think about additional abstract layer as controller who create manager and bind C to C++.
Yeah, but there are (about FTM) half of file such small functions and bindings and it's become harder to read high-level taskbar API. I think about additional abstract layer as controller who create manager and bind C to C++.
I don't think this is worth the effort. You will probably end up with more code doing exactly the same thing, which in the end will be even worse to read.
Any news about this? I would love this feature. I usually have dozens of windows open on multiple workspaces, and a taskbar is only useful if only the tasks on this workspace are shown :) Thank you for constantly adding great features!
@AGCaesar The PRs and MRs to get the base workspace functionality working are still waiting to be merged. If they are merged another protocol PR is missing to know which toplevel (window) is on which workspace. Once this is also merged, we can move forward and implement this feature in waybar.
Hello there, any news about this? I would like to have such option. Couldn't find a PR related to this.
Hello there, any news about this? I would like to have such option. Couldn't find a PR related to this.
There are no PR for this feature yet. We are waiting for workspace protocol merging.
Hello there, any news about this? I would like to have such option. Couldn't find a PR related to this.
There are no PR for this feature yet. We are waiting for workspace protocol merging.
Can I help in some way?
Probably not. We have to be patient and wait for the upstream developers to have a proper look at the PRs so that they can be merged or improved if necessary.
