[GH-ISSUE #639] [Workspaces] Workspaces renamed with name_map incorrectly being shown as active #3024

New issue

Closed

opened 2026-05-22 23:53:23 +01:00 by JakeStanger · 2 comments

JakeStanger commented

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

Owner

Originally created by @michaelBelsanti on GitHub (Jun 10, 2024).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/639

Describe the bug
I am using this configuration:

      "all_monitors": false,
      "name_map": {
        "11": "1",
        "12": "2",
        "13": "3",
        "14": "4",
        "15": "5",
        "16": "6",
        "17": "7",
        "18": "8",
        "19": "9"
      },
      "type": "workspaces"

I have workspaces 11-19 assigned to my second monitor. There is a bug occurring where whichever workspace is currently focused, is shown as the active workspace for both monitors. Eg. if I am on workspace 1 on my main monitor, the bar on my other monitor will also show workspace 1 as active, even though this workspace is actually 11 being renamed to 1. It seems that when a workspace is renamed using name_map, it is being treated the same as the original workspace.

To Reproduce
Steps to reproduce the behavior:

Rename workspaces with name_map in the way shown above
Focus workspace 1 on your primary monitor
See that workspace 1 on the other monitor is also shown as active.

Expected behavior
The 1st workspace on my second monitor should not be shown as active.

System information:

Distro: nixos-unstable
Compositor: Hyprland
Ironbar version: ironbar 0.16.0-pre [rev b0132b]

Configuration

Share your bar configuration and stylesheet as applicable:
https://github.com/michaelBelsanti/nixconfig/blob/main/modules/nixos/desktops/hyprland/ironbar.nix
https://github.com/michaelBelsanti/nixconfig/blob/main/modules/home/theming/catppuccin/ironbar.nix

Screenshots
Both workspaces being active. Right monitor is primary, left is secondary. Left monitor is actually on workspace 2, but workspace 1 is being focused on the right monitor, so the bar is showing it as active for both.

Originally created by @michaelBelsanti on GitHub (Jun 10, 2024). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/639 **Describe the bug** I am using this configuration: ``` "all_monitors": false, "name_map": { "11": "1", "12": "2", "13": "3", "14": "4", "15": "5", "16": "6", "17": "7", "18": "8", "19": "9" }, "type": "workspaces" ``` I have workspaces 11-19 assigned to my second monitor. There is a bug occurring where whichever workspace is currently focused, is shown as the active workspace for both monitors. Eg. if I am on workspace 1 on my main monitor, the bar on my other monitor will also show workspace 1 as active, even though this workspace is actually 11 being renamed to 1. It seems that when a workspace is renamed using name_map, it is being treated the same as the original workspace. **To Reproduce** Steps to reproduce the behavior: 1. Rename workspaces with name_map in the way shown above 2. Focus workspace 1 on your primary monitor 3. See that workspace 1 on the other monitor is also shown as active. **Expected behavior** The 1st workspace on my second monitor should not be shown as active. **System information:** - Distro: nixos-unstable - Compositor: Hyprland - Ironbar version: ironbar 0.16.0-pre [rev b0132b] **Configuration** > Share your bar configuration and stylesheet as applicable: https://github.com/michaelBelsanti/nixconfig/blob/main/modules/nixos/desktops/hyprland/ironbar.nix https://github.com/michaelBelsanti/nixconfig/blob/main/modules/home/theming/catppuccin/ironbar.nix **Screenshots** Both workspaces being active. Right monitor is primary, left is secondary. Left monitor is actually on workspace 2, but workspace 1 is being focused on the right monitor, so the bar is showing it as active for both. ![image](https://github.com/JakeStanger/ironbar/assets/62124625/d7a94863-5c8f-41c3-9a23-051c6c0d4e64)

JakeStanger closed this issue

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

JakeStanger commented

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

Author

Owner

@JakeStanger commented on GitHub (Aug 11, 2024):

Thanks for reporting & apologies for the delay. I thought this was going to be a nasty one but a nice easy fix. I'll merge in a few mins and the fix will be in -git

@JakeStanger commented on GitHub (Aug 11, 2024): Thanks for reporting & apologies for the delay. I thought this was going to be a nasty one but a nice easy fix. I'll merge in a few mins and the fix will be in -git

JakeStanger commented

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

Author

Owner

@michaelBelsanti commented on GitHub (Aug 11, 2024):

Thanks for reporting & apologies for the delay. I thought this was going to be a nasty one but a nice easy fix. I'll merge in a few mins and the fix will be in -git

glad it was so simple. I assumed the same thing when I made this bug haha. turns out it was simpler to fix than it was to explain the bug lmao

@michaelBelsanti commented on GitHub (Aug 11, 2024): > Thanks for reporting & apologies for the delay. I thought this was going to be a nasty one but a nice easy fix. I'll merge in a few mins and the fix will be in -git glad it was so simple. I assumed the same thing when I made this bug haha. turns out it was simpler to fix than it was to explain the bug lmao