mirror of
https://github.com/JakeStanger/ironbar.git
synced 2026-07-11 06:15:21 +01:00
[GH-ISSUE #820] ext-workspace support #254
Labels
No labels
A:Build
A:CI
A:Client
A:Config
A:Core
A:Documentation
A:Documentation
A:IPC
A:Testing
A:UX/UI
blocked
BREAKING CHANGE
duplicate
good first issue
GTK4
help wanted
invalid
M:Battery
M:Battery
M:Bindmode
M:Bluetooth
M:Brightness
M:Cairo
M:Clipboard
M:Clock
M:Clock
M:Custom
M:Focused
M:Keyboard
M:Launcher
M:Menu
M:Music
M:Music
M:Music
M:Network Manager
M:Notifications
M:SysInfo
M:Tray
M:Volume
M:Workspaces
partially resolved
P:Critical
P:High
P:Low
P:Medium
pull-request
T:Bug
T:Bug
T:Core Enhancement
T:Module Enhancement
T:New Module
T:Question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
JakeStanger/ironbar#254
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ToxicMushroom on GitHub (Dec 22, 2024).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/820
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
@JakeStanger commented on GitHub (Dec 22, 2024):
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
@Brisingr05 commented on GitHub (Jun 15, 2025):
Niri will be implementing ext-workspace in https://github.com/YaLTeR/niri/pull/1800.
@JakeStanger commented on GitHub (Jun 26, 2025):
Hyprland has merged support
@Brisingr05 commented on GitHub (Jul 13, 2025):
Niri has also merged support: https://github.com/YaLTeR/niri/issues/135#issuecomment-3066726736
@leoVici9 commented on GitHub (Aug 31, 2025):
this is the only reason why i do not use ironbar on mangowc. mangowc just merged support.
@JakeStanger commented on GitHub (Oct 26, 2025):
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-workspacesbranch).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:
Compositors seem to be implementing it as follows though:
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?
@Consolatis commented on GitHub (Oct 26, 2025):
Labwc only uses the
activestate (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 atagis represented as aworkspaceand thus multiple workspaces within a single group can be active at the same time.@JakeStanger commented on GitHub (Oct 26, 2025):
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?
@Consolatis commented on GitHub (Oct 26, 2025):
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 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
activestate not set.@JakeStanger commented on GitHub (Oct 27, 2025):
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:
The current workspace module offers a
.focusedcss 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.
@Brisingr05 commented on GitHub (Oct 27, 2025):
Pinging @YaLTeR, in case you have any thoughts on this.
@YaLTeR commented on GitHub (Oct 27, 2025):
IIRC:
@leoVici9 commented on GitHub (Oct 27, 2025):
@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.
@JakeStanger commented on GitHub (Oct 27, 2025):
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@xMAC94x commented on GitHub (Oct 29, 2025):
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.
@azertyfun commented on GitHub (Nov 20, 2025):
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-workspacesbranch? 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).@JakeStanger commented on GitHub (Nov 20, 2025):
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.
@Nathan22211 commented on GitHub (Dec 22, 2025):
I will note that Labwc doesn't have any kind of IPC to it, at least in mainline.
@bluebyt commented on GitHub (Feb 1, 2026):
I wanted to ask about the current status of ext-workspace-v1 suppor?
I saw that ext-workspace-v1 was merged into wlroots this week, which is great news.
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/5115
I’m planning to test the feat/ext-workspaces branch as soon as Wayfire supports it
@JakeStanger commented on GitHub (Feb 1, 2026):
As far as I'm aware support is as detailed here:
https://wayland.app/protocols/ext-workspace-v1#compositor-support
Wlroots has support which should be great for improving support soon. 'm still holding out for Sway support before finishing the branch.
@xMAC94x commented on GitHub (Mar 18, 2026):
Hey, I added a branch here: https://github.com/xMAC94x/ironbar/tree/xMAC94x/feat/ext-workspaces
which works for my machine. anyone wanna test it out ? It needs some finishing touch though
@bluebyt commented on GitHub (Mar 19, 2026):
I can try it on Hyprland, but do I need to change the config files? How can I check if I’m using ext-workspace?
Later, I’m planning to use it with Wayfire, but for that I need to wait for the next release of wlroots 0.20, which will support ext-workspace
@JakeStanger commented on GitHub (Mar 28, 2026):
If it's in a working state, feel free to open a (draft) PR. Would be good to formalise it.
@JakeStanger commented on GitHub (Apr 22, 2026):
I've opened #1465 as a draft PR with @xMAC94x's commits cherry-picked in. I've given it a very quick test and it seems to do the basics fine.
It should default to
ext-workspacesso no configuration needed. You can confirm by running withIRONBAR_LOG=ironbar::clients::compositor=debugand checking for:I'm currently hoping to get 0.19.0 out fairly soon, once some more of the pressing bugs are out, followed by a 0.19.1 for more bug squashing. The aim is to then get this in early on during 0.20.0 development to give a big testing window.