JakeStanger/ironbar

Fork 0

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

[GH-ISSUE #1458] Workspaces widget tries to move to invalid workspace when the workspace in question is named #443

New issue

Open

opened 2026-05-22 21:53:22 +01:00 by JakeStanger · 3 comments

JakeStanger commented

2026-05-22 21:53:22 +01:00

Owner

Originally created by @fhungus on GitHub (Apr 18, 2026).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1458

Describe the bug
When the workspaces in Hyprland are named, on click of one of the widgets, you are either moved to workspace 1 or attempted to be moved to a large, negative number.

To reproduce
Steps to reproduce the behavior:

Rename workspaces in compositor to w1 - w9
Open windows in some of the workspaces
Try to click on aforementioned workspaces
You will instead be switched to either workspace 1, or will get an error in the logs stating that it "couldn't focus the workspace", with a workspace that Hyprland cannot move to.
Expected behavior
It should have switched to the appropriate workspace.

System information:

Distro: EndeavourOS
Compositor: Hyprland
Ironbar version: 0.18.0

Configuration
This seems to still happen on the default configuration.

Additional context
The first time i observed this error the negative number it tried to switch to was -1337, which didn't look coincidental, so I thought could be a default in case the widget couldn't properly get the number, but the codebase does not have a mention of the number 1337, nor does the hyprland-rs crate.
However, for some reason, the number is no longer -1337.

This doesn't seem to be limited to specifically the names mentioned either, on my system anything will work. The reason I had to rename these in the first place is because for some reason GTK's CSS will not accept leading numbers when selecting based on ID, and I'm trying to theme each workspace differently.

Screenshots

Originally created by @fhungus on GitHub (Apr 18, 2026). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1458 **Describe the bug** When the workspaces in Hyprland are named, on click of one of the widgets, you are either moved to workspace 1 or attempted to be moved to a large, negative number. **To reproduce** Steps to reproduce the behavior: 1. Rename workspaces in compositor to w1 - w9 2. Open windows in some of the workspaces 3. Try to click on aforementioned workspaces 4. You will instead be switched to either workspace 1, or will get an error in the logs stating that it "couldn't focus the workspace", with a workspace that Hyprland cannot move to. **Expected behavior** It should have switched to the appropriate workspace. **System information:** - Distro: EndeavourOS - Compositor: Hyprland - Ironbar version: 0.18.0 **Configuration** This seems to still happen on the default configuration. **Additional context** The first time i observed this error the negative number it tried to switch to was -1337, which didn't look coincidental, so I thought could be a default in case the widget couldn't properly get the number, but the codebase does not have a mention of the number 1337, nor does the hyprland-rs crate. However, for some reason, the number is no longer -1337. This doesn't seem to be limited to specifically the names mentioned either, on my system anything will work. The reason I had to rename these in the first place is because for some reason GTK's CSS will not accept leading numbers when selecting based on ID, and I'm trying to theme each workspace differently. **Screenshots** <img width="923" height="130" alt="Image" src="https://github.com/user-attachments/assets/c2df644a-614e-4335-9112-8b133cdc80a6" /> <img width="149" height="44" alt="Image" src="https://github.com/user-attachments/assets/e0812004-88da-45c0-a220-1a8a5a14c13e" />

JakeStanger added the

labels

2026-05-22 21:53:22 +01:00

JakeStanger commented

2026-05-22 21:53:23 +01:00

Author

Owner

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

Related: #964

I don't think it's quite the same issue but definitely stems from the same problem.

@JakeStanger commented on GitHub (Apr 22, 2026): Related: #964 I don't think it's quite the same issue but definitely stems from the same problem.

JakeStanger commented

2026-05-22 21:53:23 +01:00

Author

Owner

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

From when I was working on the other workspace issues all the reading I did mentioned Hyprland using large negative numbers to represent named unnumbered workspaces. -1337 in particular appears to be a common default value that hyprland will use.

@CameronBarnes commented on GitHub (Apr 23, 2026): From when I was working on the other workspace issues all the reading I did mentioned Hyprland using large negative numbers to represent named unnumbered workspaces. -1337 in particular appears to be a common default value that hyprland will use.

JakeStanger commented

2026-05-22 21:53:23 +01:00

Author

Owner

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

I havent been unable to reproduce this problem. @fhungus Can you be more specific about the following things please.

How and at what point are you actually renaming the workspaces.
Does this issue occur on the latest version of hyprland? I'm currently running 0.54.3 myself
Please share your config

Depending on how exactly this is setup, it's possible that this is caused by the known issue with named favorite workspaces, but I'm not sure.

@CameronBarnes commented on GitHub (Apr 25, 2026): I havent been unable to reproduce this problem. @fhungus Can you be more specific about the following things please. 1. How and at what point are you actually renaming the workspaces. 2. Does this issue occur on the latest version of hyprland? I'm currently running 0.54.3 myself 3. Please share your config Depending on how exactly this is setup, it's possible that this is caused by the known issue with named favorite workspaces, but I'm not sure.

Rows
Columns