JakeStanger/ironbar

Fork 0

mirror of https://github.com/JakeStanger/ironbar.git synced 2026-07-11 06:15:21 +01:00

[GH-ISSUE #964] (Re upload) Workspace buttons disappear #7320

New issue

Open

opened 2026-05-23 02:53:53 +01:00 by JakeStanger · 7 comments

JakeStanger commented

2026-05-23 02:53:53 +01:00

Owner

Originally created by @lordmujin on GitHub (May 9, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/964

Describe the bug
When switching workspaces, after hyprland and ironbar start, if I switch to another workspace, the one I was at the start vanishes. If I do ironbar reload it goes back to normal but the behavior repeats.

Duplicate of: https://github.com/JakeStanger/ironbar/issues/464

To Reproduce
Set favorite workspaces, start hyprland in this case, switch workspaces, and sometimes it works correctly, but fails more often.

Expected behavior
That all favorite workspaces are persistent

System information:

Distro: NixOS
Compositor: Hyprland
Ironbar version: 0.16.1 (nix-unstable)

Configuration

Config

{ "type": "workspaces",
		  "name_map": {
  		  	"1": "一",
  		  	"2": "二",
  		  	"3": "三",
  		  	"4": "四",
  		  	"5": "五"
  		  },
		  "favorites": ["1", "2", "3", "4", "5"],
		  "hidden": ["special:scratch_music", "special:scratch_term", "special:special"]
  		}

Styles

.workspaces {
	margin-left: 10px;
}

.workspaces .item.focused {
	color: @blue;
	background-color: @gray-dark;
    box-shadow: inset 0 -3px;
}

.workspaces .item.urgent {
    background-color: @red;
}

.workspaces .item:hover {
	color: @sky;
	background-color: @base;
    box-shadow: inset 0 -3px;
}

Additional context

Screenshots

Originally created by @lordmujin on GitHub (May 9, 2025). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/964 **Describe the bug** When switching workspaces, after hyprland and ironbar start, if I switch to another workspace, the one I was at the start vanishes. If I do `ironbar reload` it goes back to normal but the behavior repeats. Duplicate of: https://github.com/JakeStanger/ironbar/issues/464 **To Reproduce** Set favorite workspaces, start hyprland in this case, switch workspaces, and sometimes it works correctly, but fails more often. **Expected behavior** That all favorite workspaces are persistent **System information:** - Distro: NixOS - Compositor: Hyprland - Ironbar version: 0.16.1 (nix-unstable) **Configuration** <details><summary>Config</summary> ``` { "type": "workspaces", "name_map": { "1": "一", "2": "二", "3": "三", "4": "四", "5": "五" }, "favorites": ["1", "2", "3", "4", "5"], "hidden": ["special:scratch_music", "special:scratch_term", "special:special"] } ``` </details> <details><summary>Styles</summary> ```css .workspaces { margin-left: 10px; } .workspaces .item.focused { color: @blue; background-color: @gray-dark; box-shadow: inset 0 -3px; } .workspaces .item.urgent { background-color: @red; } .workspaces .item:hover { color: @sky; background-color: @base; box-shadow: inset 0 -3px; } ``` </details> **Additional context** [](https://github.com/JakeStanger/ironbar/issues/464) **Screenshots**

JakeStanger added the

labels

2026-05-23 02:53:53 +01:00

JakeStanger commented

2026-05-23 02:53:53 +01:00

Author

Owner

@psynyde commented on GitHub (May 10, 2025):

Facing the same issue with same specs. (same os, wm and ironbar version)

@psynyde commented on GitHub (May 10, 2025): Facing the same issue with same specs. (same os, wm and ironbar version)

JakeStanger commented

2026-05-23 02:53:53 +01:00

Author

Owner

@JakeStanger commented on GitHub (May 18, 2025):

I've not been able to replicate this. I'm going to need some more information around the repro steps please.

Specifics like which workspaces you're switching to/from, whether there's anything open on those workspaces, etc are very helpful.

If you can also please capture debug logs using:

IRONBAR_LOG='ironbar::modules::workspaces=debug,ironbar::clinets::compositor=debug'

that will hopefully give some insight into what's happening under the hood.

@JakeStanger commented on GitHub (May 18, 2025): I've not been able to replicate this. I'm going to need some more information around the repro steps please. Specifics like *which* workspaces you're switching to/from, whether there's anything open on those workspaces, etc are very helpful. If you can also please capture debug logs using: ``` IRONBAR_LOG='ironbar::modules::workspaces=debug,ironbar::clinets::compositor=debug' ``` that will hopefully give some insight into what's happening under the hood.

JakeStanger commented

2026-05-23 02:53:53 +01:00

Author

Owner

@lordmujin commented on GitHub (May 18, 2025):

Thanks for the tip, its a odd behavior, I noticed it happens when the workspace has no window open, and it can happen in any.
I started ironbar with logs it, I was in workspace 2 and moved to workspace 3, workspace 2 disappears and the others behave correctly

2025-05-18T21:13:31.354034Z DEBUG ironbar::modules::workspaces: 221: Received update: Init([Workspace { id: -98, name: "special:scratch_music", monitor: "DP-1", visibility: Hidden }, Workspace { id: 1, name: "1", monitor: "DP-1", visibility: Hidden }, Workspace { id: 2, name: "2", monitor: "DP-1", visibility: Visible(true) }])`
2025-05-18T21:13:35.213450Z DEBUG ironbar::modules::workspaces: 221: Received update: Add(Workspace { id: 3, name: "3", monitor: "DP-1", visibility: Visible(false) })`
2025-05-18T21:13:35.214934Z DEBUG ironbar::modules::workspaces: 221: Received update: Focus { old: Some(Workspace { id: 2, name: "2", monitor: "DP-1", visibility: Visible(true) }), new: Workspace { id: 3, name: "3", monitor: "DP-1", visibility: Visible(false) } }`
2025-05-18T21:13:35.214984Z DEBUG ironbar::modules::workspaces: 221: Received update: Remove(2)`
2025-05-18T21:13:45.831175Z DEBUG ironbar::modules::workspaces: 221: Received update: Add(Workspace { id: 4, name: "4", monitor: "DP-1", visibility: Visible(false) })`
2025-05-18T21:13:45.832056Z DEBUG ironbar::modules::workspaces: 221: Received update: Focus { old: Some(Workspace { id: 3, name: "3", monitor: "DP-1", visibility: Visible(false) }), new: Workspace { id: 4, name: "4", monitor: "DP-1", visibility: Visible(false) } }`
2025-05-18T21:13:45.832107Z DEBUG ironbar::modules::workspaces: 221: Received update: Remove(3)`

@lordmujin commented on GitHub (May 18, 2025): Thanks for the tip, its a odd behavior, I noticed it happens when the workspace has no window open, and it can happen in any. I started ironbar with logs it, I was in workspace 2 and moved to workspace 3, workspace 2 disappears and the others behave correctly ``` 2025-05-18T21:13:31.354034Z DEBUG ironbar::modules::workspaces: 221: Received update: Init([Workspace { id: -98, name: "special:scratch_music", monitor: "DP-1", visibility: Hidden }, Workspace { id: 1, name: "1", monitor: "DP-1", visibility: Hidden }, Workspace { id: 2, name: "2", monitor: "DP-1", visibility: Visible(true) }])` 2025-05-18T21:13:35.213450Z DEBUG ironbar::modules::workspaces: 221: Received update: Add(Workspace { id: 3, name: "3", monitor: "DP-1", visibility: Visible(false) })` 2025-05-18T21:13:35.214934Z DEBUG ironbar::modules::workspaces: 221: Received update: Focus { old: Some(Workspace { id: 2, name: "2", monitor: "DP-1", visibility: Visible(true) }), new: Workspace { id: 3, name: "3", monitor: "DP-1", visibility: Visible(false) } }` 2025-05-18T21:13:35.214984Z DEBUG ironbar::modules::workspaces: 221: Received update: Remove(2)` 2025-05-18T21:13:45.831175Z DEBUG ironbar::modules::workspaces: 221: Received update: Add(Workspace { id: 4, name: "4", monitor: "DP-1", visibility: Visible(false) })` 2025-05-18T21:13:45.832056Z DEBUG ironbar::modules::workspaces: 221: Received update: Focus { old: Some(Workspace { id: 3, name: "3", monitor: "DP-1", visibility: Visible(false) }), new: Workspace { id: 4, name: "4", monitor: "DP-1", visibility: Visible(false) } }` 2025-05-18T21:13:45.832107Z DEBUG ironbar::modules::workspaces: 221: Received update: Remove(3)` ```

JakeStanger commented

2026-05-23 02:53:53 +01:00

Author

Owner

@ApproachingApathy commented on GitHub (Jun 17, 2025):

I have a similar issue. Workspace buttons get stuck on whatever monitor they spawned on. When I move a workspace to another monitor, the button stays on the existing monitor.

Start a multi-monitor hyprland setup.
Move a workspace to a different monitor.
The workspace button will not switch to the new monitor.

Config and Versions

Work space config:

[[start]]
type = "workspaces"
all_monitors = false
icon_size = 6

Versions

Hyprland 0.49.0 built from branch  at commit 9958d297641b5c84dcff93f9039d80a5ad37ab00  (version: bump to 0.49.0).
Tag: v0.49.0, commits: 6098

ironbar 0.16.1

@ApproachingApathy commented on GitHub (Jun 17, 2025): I have a similar issue. Workspace buttons get stuck on whatever monitor they spawned on. When I move a workspace to another monitor, the button stays on the existing monitor. 1. Start a multi-monitor hyprland setup. 2. Move a workspace to a different monitor. 3. The workspace button will not switch to the new monitor. <details> <summary>Config and Versions</summary> Work space config: ``` [[start]] type = "workspaces" all_monitors = false icon_size = 6 ``` Versions ``` Hyprland 0.49.0 built from branch at commit 9958d297641b5c84dcff93f9039d80a5ad37ab00 (version: bump to 0.49.0). Tag: v0.49.0, commits: 6098 ``` ``` ironbar 0.16.1 ``` </details>

JakeStanger commented

2026-05-23 02:53:53 +01:00

Author

Owner

@CameronBarnes commented on GitHub (Apr 2, 2026):

I believe I have encountered similar behavior and can explain how it's occurring and submit a fix that covers at least some cases.

My config defines a series of numbered favorites for each monitor. Selecting one of those favorites(lets say 5 for example) that is not already open does not open a new workspace, because favorites by default appear to have an id of -1, which obviously isnt our example id of 5. ironbar just assumes the name will be enough, but as far as I can tell that information is never passed to hyprland.

When manually opening a favorite workspace(such as with a keybind) that ironbar button will work correctly as long as the workspace has contents. But when it is no longer present the remove_workspace behavior gets triggered and either removes the component entirely or sets the button id to the invalid value of -1.

I addressed this by having the favorite buttons set the workspace id to the same value as the name when it is a valid i64 and then had the remove_workspace behavior ignore buttons where the id is the name of a favorite on the current monitor. This likely will leave a similar issue outstanding with named workspaces, but I wouldnt be sure how to go about resolving that.

Please let me know if you'd like me to submit a PR for this issue. Or if there needs to be more discussion about addressing named workspaces. I've probably already spent significantly more time tracing all the channel signals through the code than I should have.

@CameronBarnes commented on GitHub (Apr 2, 2026): I believe I have encountered similar behavior and can explain how it's occurring and submit a fix that covers at least some cases. My config defines a series of numbered favorites for each monitor. Selecting one of those favorites(lets say 5 for example) that is not already open does not open a new workspace, because favorites by default appear to have an id of -1, which obviously isnt our example id of 5. ironbar just assumes the name will be enough, but as far as I can tell that information is never passed to hyprland. When manually opening a favorite workspace(such as with a keybind) that ironbar button will work correctly as long as the workspace has contents. But when it is no longer present the remove_workspace behavior gets triggered and either removes the component entirely or sets the button id to the invalid value of -1. I addressed this by having the favorite buttons set the workspace id to the same value as the name when it is a valid i64 and then had the remove_workspace behavior ignore buttons where the id is the name of a favorite on the current monitor. This likely will leave a similar issue outstanding with named workspaces, but I wouldnt be sure how to go about resolving that. Please let me know if you'd like me to submit a PR for this issue. Or if there needs to be more discussion about addressing named workspaces. I've probably already spent significantly more time tracing all the channel signals through the code than I should have.

JakeStanger commented

2026-05-23 02:53:53 +01:00

Author

Owner

@JakeStanger commented on GitHub (Apr 2, 2026):

A partial fix sounds good for now. I'm not sure how resolvable the name issue will be, but will be worth readdressing that once ext-workspave support is in. Thanks for taking the time to investigate.

@JakeStanger commented on GitHub (Apr 2, 2026): A partial fix sounds good for now. I'm not sure how resolvable the name issue will be, but will be worth readdressing that once ext-workspave support is in. Thanks for taking the time to investigate.

JakeStanger commented

2026-05-23 02:53:53 +01:00

Author

Owner

@CameronBarnes commented on GitHub (Apr 2, 2026):

I've created pull request #1439 for this issue and the partial fix

@CameronBarnes commented on GitHub (Apr 2, 2026): I've created pull request #1439 for this issue and the partial fix