ironbar
ironbar copied to clipboard
JakeStanger
ext-workspace support
Is your feature request related to a problem? Please describe. Currently the supported compositors for workspace module is very limited and requires compositor specific implementations. This is a newly merged wayland protocol for workspaces that aims to unify this process
Describe the solution you'd like Use this protocol in the workspace module. Ironbar can then hopefully be used to show workspaces on any comp that implements this protocol :)
I think sway already does since it was based on their wlr workspace thing but not sure.
Describe alternatives you've considered /
Additional context https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40
I'd like to see both of Sway and Hyprland support the protocol first, as those are the two with merged support for the module. Once they ship releases, I'll definitely be happy to move away from relying on their IPCs
https://wayland.app/protocols/ext-workspace-v1
Niri will be implementing ext-workspace in https://github.com/YaLTeR/niri/pull/1800.
Niri has also merged support: https://github.com/YaLTeR/niri/issues/135#issuecomment-3066726736
this is the only reason why i do not use ironbar on mangowc. mangowc just merged support.
I've started working on this in the past few days, and I've gotten to the point where I can log events from the protocol (you can test this on the feat/ext-workspaces branch).
After testing on Hyprland, Niri and COSMIC, it seems like the protocol has been (consistently) incorrectly implemented.
I've additionally not tested Jay but from reading the code, it looks to do the same thing. LabWC looks like it uses all three states from the code, but I've not been able to get it working well enough to test.
https://wayland.app/protocols/ext-workspace-v1#ext_workspace_handle_v1:enum:state
The protocol offers 3 state values for a workspace, which I would interpret as follows:
- Active: The workspace is currently focused
- Urgent: The workspace has something requesting attention
- Hidden: The workspace is open, but not currently visible
Compositors seem to be implementing it as follows though:
- Active: The workspace is currently visible
- Urgent: The workspace has something requesting attention
- Hidden: Not used
This seems muddled up to me, and importantly makes representing the focused state through the protocol impossible. This is important for multi-monitor setups. For example, I've got 3 screens, so Hyprland reports 3 active workspaces. How can I tell which one is focused?
I will see if I can get something together still, as support without that would be better than no support at all. I think this needs fixing at a compositor-level before Ironbar can offer a full implementation still though.
I'm interested to see if anybody interprets this differently?
LabWC looks like it uses all three states from the code
Labwc only uses the active state (the protocol implementation itself supports everything from the protocol though, that was done to allow migrating the implementation to wlroots). Note that this protocol is written in a way that also supports tag-based compositors (a la awesomewm). In that case a tag is represented as a workspace and thus multiple workspaces within a single group can be active at the same time.
It still seems to me even in that case it should only be active if it actually has focus. The hidden flag should be used to indicate when the tag is not enabled surely?
It still seems to me even in that case it should only be active if it actually has focus.
Can you elaborate on the use-case? You mean like keyboard-focus, so that a panel can show that keyboard actions will affect this specific workspace? I have a feeling that groups could have a focus state / focus events but not workspaces. E.g. what would be the "focused" workspace in a tag-based compositor.
The hidden flag should be used to indicate when the tag is not enabled surely?
The intention for that one is to completely hide this workspace from bars. As far as I remember that one was added for internal workspaces like the sway scratchpad (which I think is used as a container for "minimized" windows).
A tag / workspace not being enabled would simply have the active state not set.
Right. It sounds like based on what you've said above, and from discussions outside of this thread, that I am indeed misinterpreting the protocol. The focused behaviour I am looking for is not part of it.
Just to clarify in case anybody stumbles across this, the correct interpretation of the states in full:
- Active: The workspace is currently visible (or tag is enabled).
- Urgent: The workspace has something requesting attention.
- Hidden: The workspace is internal such as a scratchpad/special workspace, and in most cases should be ignored by shells and bars.
Can you elaborate on the use-case?
The current workspace module offers a .focused css class, meaning "this workspace current has [a client with] keyboard/mouse focus". This is differentiated from an active workspace, which just means it's visible (or enabled in the case of tags). It is useful for multi-monitor setups. All of the Sway/Hyprland/Niri IPC implementations offer this information.
As this isn't in the protocol, that will either have to be dropped, or there will need to be a layer of IPC implementations on top just to bring it in.
IIRC:
- active does not imply focus, just that it's the "active" workspace (windows are visible, etc.)
- hidden is for like scratch workspaces that should not be displayed on the bar
- there's no keyboard focus state
@JakeStanger. A.layer of ipc on top of ext-workspace-v1 does not sound like a very healthy solution even from a users perspective. I would be very happy with a solution that does not support .focused and allows me to use ironbar on a ext-workspace-v1 compliant compositor. But yeah might mean having to duplicate code and adding a switch on workspaces.
Any solution that's implemented for this will be transparent for the user. I'm intending to have no additional configuration necessary. If an IPC implementation exists, it will add the additional functionality. If it doesn't, some features (namely .focused, I'm not expecting anything else currently) won't work. That ideally should be no more visible than a logged warning
Hi, I am currently on pinnaclewm which depends on ext-workspace for bars. I would be very happy with a basic implementation that does not implement <workspace that has a keyboard/mouse focused window on them> for now.
And then wait for the workgroup to maybe extend the official protocol.
I will later try out your branch to confirm wheather it works or has issues.
Any solution that's implemented for this will be transparent for the user. I'm intending to have no additional configuration necessary. If an IPC implementation exists, it will add the additional functionality. If it doesn't, some features (namely
.focused, I'm not expecting anything else currently) won't work. That ideally should be no more visible than a logged warning
Yeah I agree with that approach. Better to collate whichever sources information exist than not have any at all.
What's the status of the feat/ext-workspaces branch? I'd be happy to contribute since I use Hyprland and the current IPC implementation triggers race conditions sometimes (though less often than before #1197 was merged).
Currently it logs events from the workspace manager and from workspaces themselves. Workspace groups aren't implemented at all, although I'm not sure how important they are to the bar impl anyway.
None of the work required to get the information from the client into the module is done yet. If you want to pick that up, go for it, but it is a lot of work still.