[GH-ISSUE #938] name_map/favorites navigation error #8713

Open
opened 2026-05-23 03:53:57 +01:00 by JakeStanger · 5 comments
Owner

Originally created by @brickfrog on GitHub (Apr 15, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/938

Describe the bug

This has happened in the last ~month but essentially when using favorites to keep workspaces visible, you can't navigate correctly with left clicks anymore out of the box.

I'm unsure if this is a hyprland regression but I believe it worked correctly after their latest update and only happened in the last week or two.

I tried some sanity checks, changing config to yaml, trying out different hypr dispatch mechanisms + on_left_click but nothing seemed to work except removing the favorites line.

To Reproduce

It seems to happen anytime name_map + favorites are used, and things work normally when favorites are removed - I tried removing the name_map and keeping favorites only, but no dice.

[[monitors."DP-3".center]]
type = "workspaces"
name_map = { "1" = "一", "2" = "二", "3" = "三", "4" = "四", "5" = "五", "6" = "六", "7" = "七", "8" = "八", "9" = "九", "10" = "十", "11" = "icon:steam" }
favorites = ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11"]
sort = "name"
on_scroll_up = "hyprctl dispatch workspace -1"
on_scroll_down = "hyprctl dispatch workspace +1"
all_monitors = false
icon_size = 18

Expected behavior

clicking simply moves one workspace down, previously it would work as one would presume - I click 10, it moves to 10, I click 9, it moves to 9, etc.

Now only the scrollbar works (with on_scroll_up/on_scroll_down) and clicking simply moves one down. I tried adding on_left_click, etc. to no avail. The only way this is solved is by removing the favorites, but then that removes the workspace being always present.

System information:

Linux 6.14.2-2-cachyos
hyprland 0.48.1-4
ironbar-git 0.16.1.r225.ge3742f8-1

Configuration

Config
# Top-level table for the "DP-3" monitor
[monitors."DP-3"]
icon_theme = "Tela-circle-nord"
position = "top"

# "start" section - each item in the list becomes an array of tables
[[monitors."DP-3".start]]
type = "custom"
[[monitors."DP-3".start.bar]]
type = "button"
name = "wlogout"
class = "wlogout"
label = "  "
on_click = "!~/.config/ironbar/scripts/wlogout"

[[monitors."DP-3".start]]
type = "custom"
[[monitors."DP-3".start.bar]]
type = "label"
name = "pacman"
class = "pacman"
label = " {{600000:checkupdates | wc -l}}"

[[monitors."DP-3".start]]
type = "focused"
show_icon = true
show_title = true
icon_size = 18
icon_theme = "Tela-circle-nord"
truncate = { mode = "end", max_length = 25 }

# "center" section - just one item, but still an array of tables
[[monitors."DP-3".center]]
type = "workspaces"
name_map = { "1" = "一", "2" = "二", "3" = "三", "4" = "四", "5" = "五", "6" = "六", "7" = "七", "8" = "八", "9" = "九", "10" = "十", "11" = "icon:steam" }
favorites = ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11"]
sort = "name"
on_scroll_up = "hyprctl dispatch workspace -1"
on_scroll_down = "hyprctl dispatch workspace +1"
all_monitors = false
icon_size = 18

# "end" section - multiple items, each as an array of tables
[[monitors."DP-3".end]]
type = "sys_info"
interval = { temps = 3, disks = 300, memory = 30, cpu = 1, networks = 3 }
format = [
  " {cpu_percent}% | {temp_c}°C",
  " {memory_used} GB ({memory_percent}%)",
  "󰋊 {disk_used:/}/{disk_total:/} GB ({disk_percent:/}%)",
]

[[monitors."DP-3".end]]
type = "volume"
format = "{icon} {percentage}%"
max_volume = 100
icons = { volume_high = " ", volume_medium = " ", volume_low = "", muted = "󰝟 " }
on_scroll_down = "wpctl set-volume @DEFAULT_SINK@ 2%-"
on_scroll_up = "wpctl set-volume @DEFAULT_SINK@ 2%+"
tooltip = "{{~/.config/ironbar/scripts/volume}}%"

[[monitors."DP-3".end]]
type = "clock"
format = "%A %m/%d/%Y"

[[monitors."DP-3".end]]
type = "tray"

[[monitors."DP-3".end]]
type = "custom"
[[monitors."DP-3".end.bar]]
type = "button"
name = "notification"
class = "notification"
label = "☰"
on_click = "!~/.config/ironbar/scripts/notification"

Originally created by @brickfrog on GitHub (Apr 15, 2025). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/938 **Describe the bug** This has happened in the last ~month but essentially when using favorites to keep workspaces visible, you can't navigate correctly with left clicks anymore out of the box. I'm unsure if this is a hyprland regression but I believe it worked correctly after their latest update and only happened in the last week or two. I tried some sanity checks, changing config to yaml, trying out different hypr dispatch mechanisms + on_left_click but nothing seemed to work except removing the favorites line. **To Reproduce** It seems to happen anytime name_map + favorites are used, and things work normally when favorites are removed - I tried removing the name_map and keeping favorites only, but no dice. ```toml [[monitors."DP-3".center]] type = "workspaces" name_map = { "1" = "一", "2" = "二", "3" = "三", "4" = "四", "5" = "五", "6" = "六", "7" = "七", "8" = "八", "9" = "九", "10" = "十", "11" = "icon:steam" } favorites = ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11"] sort = "name" on_scroll_up = "hyprctl dispatch workspace -1" on_scroll_down = "hyprctl dispatch workspace +1" all_monitors = false icon_size = 18 ``` **Expected behavior** clicking simply moves one workspace down, previously it would work as one would presume - I click 10, it moves to 10, I click 9, it moves to 9, etc. Now only the scrollbar works (with on_scroll_up/on_scroll_down) and clicking simply moves one down. I tried adding on_left_click, etc. to no avail. The only way this is solved is by removing the favorites, but then that removes the workspace being always present. **System information:** Linux 6.14.2-2-cachyos hyprland 0.48.1-4 ironbar-git 0.16.1.r225.ge3742f8-1 **Configuration** <details><summary>Config</summary> ``` # Top-level table for the "DP-3" monitor [monitors."DP-3"] icon_theme = "Tela-circle-nord" position = "top" # "start" section - each item in the list becomes an array of tables [[monitors."DP-3".start]] type = "custom" [[monitors."DP-3".start.bar]] type = "button" name = "wlogout" class = "wlogout" label = "  " on_click = "!~/.config/ironbar/scripts/wlogout" [[monitors."DP-3".start]] type = "custom" [[monitors."DP-3".start.bar]] type = "label" name = "pacman" class = "pacman" label = " {{600000:checkupdates | wc -l}}" [[monitors."DP-3".start]] type = "focused" show_icon = true show_title = true icon_size = 18 icon_theme = "Tela-circle-nord" truncate = { mode = "end", max_length = 25 } # "center" section - just one item, but still an array of tables [[monitors."DP-3".center]] type = "workspaces" name_map = { "1" = "一", "2" = "二", "3" = "三", "4" = "四", "5" = "五", "6" = "六", "7" = "七", "8" = "八", "9" = "九", "10" = "十", "11" = "icon:steam" } favorites = ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11"] sort = "name" on_scroll_up = "hyprctl dispatch workspace -1" on_scroll_down = "hyprctl dispatch workspace +1" all_monitors = false icon_size = 18 # "end" section - multiple items, each as an array of tables [[monitors."DP-3".end]] type = "sys_info" interval = { temps = 3, disks = 300, memory = 30, cpu = 1, networks = 3 } format = [ " {cpu_percent}% | {temp_c}°C", " {memory_used} GB ({memory_percent}%)", "󰋊 {disk_used:/}/{disk_total:/} GB ({disk_percent:/}%)", ] [[monitors."DP-3".end]] type = "volume" format = "{icon} {percentage}%" max_volume = 100 icons = { volume_high = " ", volume_medium = " ", volume_low = "", muted = "󰝟 " } on_scroll_down = "wpctl set-volume @DEFAULT_SINK@ 2%-" on_scroll_up = "wpctl set-volume @DEFAULT_SINK@ 2%+" tooltip = "{{~/.config/ironbar/scripts/volume}}%" [[monitors."DP-3".end]] type = "clock" format = "%A %m/%d/%Y" [[monitors."DP-3".end]] type = "tray" [[monitors."DP-3".end]] type = "custom" [[monitors."DP-3".end.bar]] type = "button" name = "notification" class = "notification" label = "☰" on_click = "!~/.config/ironbar/scripts/notification" ``` </details>
Author
Owner

@JakeStanger commented on GitHub (Apr 15, 2025):

Thanks for reporting. Do you get any error/warning logs out when you click and nothing happens?

<!-- gh-comment-id:2805120961 --> @JakeStanger commented on GitHub (Apr 15, 2025): Thanks for reporting. Do you get any error/warning logs out when you click and nothing happens?
Author
Owner

@brickfrog commented on GitHub (Apr 15, 2025):

Hmm, not that I see:

λ ~/ ironbar
2025-04-15T14:07:39.940262Z  INFO ironbar: 135: Ironbar version 0.16.1
2025-04-15T14:07:39.940274Z  INFO ironbar: 136: Starting application
2025-04-15T14:07:39.973418Z  WARN ironbar::ipc::server: 33: Socket already exists. Did Ironbar exit abruptly?
2025-04-15T14:07:39.973448Z  WARN ironbar::ipc::server: 34: Attempting IPC shutdown to allow binding to address
2025-04-15T14:07:39.973499Z  INFO ironbar::ipc::server: 39: Starting IPC on /run/user/1000/ironbar-ipc.sock
2025-04-15T14:07:39.974600Z  INFO ironbar::bar: 122: Initializing bar 'bar-24' on 'DP-3'
2025-04-15T14:07:39.976599Z  INFO ironbar::clients::compositor::hyprland: 39: Starting Hyprland event listener
2025-04-15T14:07:40.001640Z  INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.63/StatusNotifierItem
2025-04-15T14:07:40.001735Z  INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.105/org/ayatana/NotificationItem/spotify_client
2025-04-15T14:07:40.001870Z  INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.101/StatusNotifierItem
2025-04-15T14:07:40.002014Z  INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.158/StatusNotifierItem
2025-04-15T14:07:40.002251Z  INFO system_tray::dbus::status_notifier_watcher: 46: new host: :1.169
2025-04-15T14:07:40.002412Z  INFO ironbar::clients::volume: 168: connected to server
2025-04-15T14:07:40.002670Z  INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.22/org/ayatana/NotificationItem/nm_applet
2025-04-15T14:07:40.003075Z  INFO system_tray::dbus::status_notifier_watcher: 137: new item: :1.22/org/ayatana/NotificationItem/nm_applet (duplicate)
2025-04-15T14:07:40.028940Z  WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled
2025-04-15T14:07:40.028981Z  WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled
2025-04-15T14:07:40.043664Z ERROR GTK: 115: [Gtk] CRITICAL: gtk_widget_set_accel_path: assertion 'GTK_IS_ACCEL_GROUP (accel_group)' failed
2025-04-15T14:07:40.043692Z ERROR GTK: 115: [Gtk] CRITICAL: gtk_widget_add_accelerator: assertion 'GTK_IS_ACCEL_GROUP (accel_group)' failed
2025-04-15T14:07:40.050781Z  WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled
2025-04-15T14:07:40.050797Z  WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled
2025-04-15T14:07:40.050806Z  WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled
2025-04-15T14:07:40.181676Z  INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.147/org/ayatana/NotificationItem/steam
2025-04-15T14:07:40.182017Z  INFO system_tray::dbus::status_notifier_watcher: 137: new item: :1.22/org/ayatana/NotificationItem/nm_applet (duplicate)
2025-04-15T14:07:40.231996Z  INFO system_tray::dbus::status_notifier_watcher: 137: new item: :1.147/org/ayatana/NotificationItem/steam (duplicate)
2025-04-15T14:07:40.238444Z  WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled
2025-04-15T14:07:41.388859Z  INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.170/org/blueman/sni
2025-04-15T14:07:41.389209Z  INFO system_tray::dbus::status_notifier_watcher: 137: new item: :1.22/org/ayatana/NotificationItem/nm_applet (duplicate)
2025-04-15T14:07:41.395802Z  WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled
2025-04-15T14:07:41.437541Z  INFO system_tray::dbus::status_notifier_watcher: 137: new item: :1.147/org/ayatana/NotificationItem/steam (duplicate)
2025-04-15T14:07:44.629945Z ERROR ironbar::clients::compositor::hyprland: 332: Couldn't focus workspace '-1': Previous workspace doesn't exist
2025-04-15T14:07:50.237406Z ERROR ironbar::clients::compositor::hyprland: 332: Couldn't focus workspace '-1': Previous workspace doesn't exist
2025-04-15T14:08:03.334258Z ERROR ironbar::clients::compositor::hyprland: 332: Couldn't focus workspace '-1': Previous workspace doesn't exist

It tries to by default do the workspace -1 on left click, then only gets the error if I'm already on one, otherwise no warnings/errors emitted.

(which is why I'm confused - left clicking = -1 is a weird default to suddenly change unless something went off-kilter between how hyprland + ironbar works, I tried various "on_click_left = "hyprctl dispatch workspace e" esque solutions but it still only does -1)

# "center" section - just one item, but still an array of tables
[[monitors."DP-3".center]]
type = "workspaces"
name_map = { "1" = "一", "2" = "二", "3" = "三", "4" = "四", "5" = "五", "6" = "六", "7" = "七", "8" = "八", "9" = "九", "10" = "十", "11" = "icon:steam" }
favorites = ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11"]
sort = "name"
on_click_left = "hyprctl dispatch workspace +1"
on_scroll_up = "hyprctl dispatch workspace -1"
on_scroll_down = "hyprctl dispatch workspace +1"
all_monitors = false
icon_size = 18

I found putting a known command in works, but it seems to fight with -1, if I spam clicks it does seem to go up +1 but it's fighting with the -1 command.

<!-- gh-comment-id:2805263945 --> @brickfrog commented on GitHub (Apr 15, 2025): Hmm, not that I see: ``` λ ~/ ironbar 2025-04-15T14:07:39.940262Z INFO ironbar: 135: Ironbar version 0.16.1 2025-04-15T14:07:39.940274Z INFO ironbar: 136: Starting application 2025-04-15T14:07:39.973418Z WARN ironbar::ipc::server: 33: Socket already exists. Did Ironbar exit abruptly? 2025-04-15T14:07:39.973448Z WARN ironbar::ipc::server: 34: Attempting IPC shutdown to allow binding to address 2025-04-15T14:07:39.973499Z INFO ironbar::ipc::server: 39: Starting IPC on /run/user/1000/ironbar-ipc.sock 2025-04-15T14:07:39.974600Z INFO ironbar::bar: 122: Initializing bar 'bar-24' on 'DP-3' 2025-04-15T14:07:39.976599Z INFO ironbar::clients::compositor::hyprland: 39: Starting Hyprland event listener 2025-04-15T14:07:40.001640Z INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.63/StatusNotifierItem 2025-04-15T14:07:40.001735Z INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.105/org/ayatana/NotificationItem/spotify_client 2025-04-15T14:07:40.001870Z INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.101/StatusNotifierItem 2025-04-15T14:07:40.002014Z INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.158/StatusNotifierItem 2025-04-15T14:07:40.002251Z INFO system_tray::dbus::status_notifier_watcher: 46: new host: :1.169 2025-04-15T14:07:40.002412Z INFO ironbar::clients::volume: 168: connected to server 2025-04-15T14:07:40.002670Z INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.22/org/ayatana/NotificationItem/nm_applet 2025-04-15T14:07:40.003075Z INFO system_tray::dbus::status_notifier_watcher: 137: new item: :1.22/org/ayatana/NotificationItem/nm_applet (duplicate) 2025-04-15T14:07:40.028940Z WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled 2025-04-15T14:07:40.028981Z WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled 2025-04-15T14:07:40.043664Z ERROR GTK: 115: [Gtk] CRITICAL: gtk_widget_set_accel_path: assertion 'GTK_IS_ACCEL_GROUP (accel_group)' failed 2025-04-15T14:07:40.043692Z ERROR GTK: 115: [Gtk] CRITICAL: gtk_widget_add_accelerator: assertion 'GTK_IS_ACCEL_GROUP (accel_group)' failed 2025-04-15T14:07:40.050781Z WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled 2025-04-15T14:07:40.050797Z WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled 2025-04-15T14:07:40.050806Z WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled 2025-04-15T14:07:40.181676Z INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.147/org/ayatana/NotificationItem/steam 2025-04-15T14:07:40.182017Z INFO system_tray::dbus::status_notifier_watcher: 137: new item: :1.22/org/ayatana/NotificationItem/nm_applet (duplicate) 2025-04-15T14:07:40.231996Z INFO system_tray::dbus::status_notifier_watcher: 137: new item: :1.147/org/ayatana/NotificationItem/steam (duplicate) 2025-04-15T14:07:40.238444Z WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled 2025-04-15T14:07:41.388859Z INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.170/org/blueman/sni 2025-04-15T14:07:41.389209Z INFO system_tray::dbus::status_notifier_watcher: 137: new item: :1.22/org/ayatana/NotificationItem/nm_applet (duplicate) 2025-04-15T14:07:41.395802Z WARN GTK: 116: [LIBDBUSMENU-GLIB] Unable to get session bus: Operation was cancelled 2025-04-15T14:07:41.437541Z INFO system_tray::dbus::status_notifier_watcher: 137: new item: :1.147/org/ayatana/NotificationItem/steam (duplicate) 2025-04-15T14:07:44.629945Z ERROR ironbar::clients::compositor::hyprland: 332: Couldn't focus workspace '-1': Previous workspace doesn't exist 2025-04-15T14:07:50.237406Z ERROR ironbar::clients::compositor::hyprland: 332: Couldn't focus workspace '-1': Previous workspace doesn't exist 2025-04-15T14:08:03.334258Z ERROR ironbar::clients::compositor::hyprland: 332: Couldn't focus workspace '-1': Previous workspace doesn't exist ``` It tries to by default do the workspace -1 on left click, then only gets the error if I'm already on one, otherwise no warnings/errors emitted. (which is why I'm confused - left clicking = -1 is a weird default to suddenly change unless something went off-kilter between how hyprland + ironbar works, I tried various "on_click_left = "hyprctl dispatch workspace e" esque solutions but it still only does -1) ```toml # "center" section - just one item, but still an array of tables [[monitors."DP-3".center]] type = "workspaces" name_map = { "1" = "一", "2" = "二", "3" = "三", "4" = "四", "5" = "五", "6" = "六", "7" = "七", "8" = "八", "9" = "九", "10" = "十", "11" = "icon:steam" } favorites = ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11"] sort = "name" on_click_left = "hyprctl dispatch workspace +1" on_scroll_up = "hyprctl dispatch workspace -1" on_scroll_down = "hyprctl dispatch workspace +1" all_monitors = false icon_size = 18 ``` I found putting a known command in works, but it seems to fight with -1, if I spam clicks it does seem to go up +1 but it's fighting with the -1 command.
Author
Owner

@brickfrog commented on GitHub (Apr 16, 2025):

I ended up brute-force AI fixing this - log attached, but I'm not a rust dev so I'm not entirely sure how hacky this is, but might point in the correct direction / assuming this doesn't bork other things:

    When using favorites, each workspace button is created with an initial id of -1 (meaning “not attached to a real
    workspace yet”).
    When a real workspace named "1" appears, the code tries to update the button’s id by calling
    btn.set_workspace_id(workspace.id).

    But:
    The original Rust code hooked up the click handler as:

        button.connect_clicked(move |_item| {
            try_send!(tx, id);
        });

    which captures the initial value of id (always -1 for favorite buttons) forever.
    So, clicking always emits -1 (or whatever it was at construction), even if the button is later updated to point at the 
    real workspace!

    ------------------------------------------------------------------------------------------------------------------------
    ---

    ## What is the fix?

    The new code changes how the ID is stored and accessed by the click handler:

        * **Before:**
            * The `Button` struct just has a field, `workspace_id: i64`.

            * Click handler captures the initial value.
        * **After:**
            * The `Button` struct’s id is now `workspace_id: Rc<RefCell<i64>>`.

            * The click handler captures a `Rc<RefCell<i64>>`, so every time you click, it “looks up” the latest id value
    from that smart pointer—**whatever most recent id has been set by `set_workspace_id`**.

    Code highlights:

        // Old
        button.connect_clicked(move |_item| {
            try_send!(tx, id);  // id is the value from creation only
        });

        // New
        let workspace_id = Rc::new(RefCell::new(id));
        let workspace_id_for_click = Rc::clone(&workspace_id);
        button.connect_clicked(move |_item| {
            let id = *workspace_id_for_click.borrow();
            try_send!(tx, id);  // Always gets the current ID
        });

        // and then updating:
        pub fn set_workspace_id(&mut self, id: i64) {
            *self.workspace_id.borrow_mut() = id;
        }
<!-- gh-comment-id:2810539417 --> @brickfrog commented on GitHub (Apr 16, 2025): I ended up brute-force AI fixing this - log attached, but I'm not a rust dev so I'm not entirely sure how hacky this is, but might point in the correct direction / assuming this doesn't bork other things: ``` When using favorites, each workspace button is created with an initial id of -1 (meaning “not attached to a real workspace yet”). When a real workspace named "1" appears, the code tries to update the button’s id by calling btn.set_workspace_id(workspace.id). But: The original Rust code hooked up the click handler as: button.connect_clicked(move |_item| { try_send!(tx, id); }); which captures the initial value of id (always -1 for favorite buttons) forever. So, clicking always emits -1 (or whatever it was at construction), even if the button is later updated to point at the real workspace! ------------------------------------------------------------------------------------------------------------------------ --- ## What is the fix? The new code changes how the ID is stored and accessed by the click handler: * **Before:** * The `Button` struct just has a field, `workspace_id: i64`. * Click handler captures the initial value. * **After:** * The `Button` struct’s id is now `workspace_id: Rc<RefCell<i64>>`. * The click handler captures a `Rc<RefCell<i64>>`, so every time you click, it “looks up” the latest id value from that smart pointer—**whatever most recent id has been set by `set_workspace_id`**. Code highlights: // Old button.connect_clicked(move |_item| { try_send!(tx, id); // id is the value from creation only }); // New let workspace_id = Rc::new(RefCell::new(id)); let workspace_id_for_click = Rc::clone(&workspace_id); button.connect_clicked(move |_item| { let id = *workspace_id_for_click.borrow(); try_send!(tx, id); // Always gets the current ID }); // and then updating: pub fn set_workspace_id(&mut self, id: i64) { *self.workspace_id.borrow_mut() = id; } ```
Author
Owner

@JakeStanger commented on GitHub (Apr 19, 2025):

Thanks for the extra info and for taking the time to look into it. Hats off to the AI for correctly identifying the problem, and that probably is the best Rust-y fix too.

The alternative path is to use set_tag and get_tag on the button widget itself. That avoids the need to wrap code in Rc<RefCell<T>> which might make things a little neater.

<!-- gh-comment-id:2816882087 --> @JakeStanger commented on GitHub (Apr 19, 2025): Thanks for the extra info and for taking the time to look into it. Hats off to the AI for correctly identifying the problem, and that probably is the best Rust-y fix too. The alternative path is to use `set_tag` and `get_tag` on the button widget itself. That avoids the need to wrap code in `Rc<RefCell<T>>` which might make things a little neater.
Author
Owner

@brickfrog commented on GitHub (Apr 20, 2025):

Ah. Darn, turns out there's still some edge cases, the buttons for empty workspaces never get their workspace_id properly updated from the initial -1 value, so in a case where you have a map/favorites, it's still the same behavior (i.e., have a 1/2/3/4/5 in chinese, and, say, you're on 4, then you click 5 (empty), instead of going to 5 you go to 3)

this ended up requiring edits to mod.rs in addition, but I think I mostly got it working - I can submit a PR if needed. - I didn't know if it was worth the temporary(?) bandaid or if this was more emblematic of how hyprland, etc. worked and was worth figuring that out

AI Notes:

Problem:

Clicking workspace buttons, particularly "favorite" workspaces, was unreliable. Favorites start as placeholders (often with an internal ID of -1) and get linked to real workspace IDs when active. If the real workspace moved away, the favorite button might reset to -1 internally. The old code couldn't handle clicks correctly in these states because:
It only sent numerical IDs, so clicking a placeholder (-1) or a named favorite ("web") failed.

Even clicking a numerically named favorite ("1") could fail if its internal ID was reset to -1, as the system wasn't designed to focus based on the name "1".

Solution:

Introduced WorkspaceRequestMessage Enum: Created a message type that can carry either a workspace Id(i64) or a Name(String).
Updated Controller: The controller now handles both message types.
Id: Focuses the workspace ID directly.
Name: Tries to parse the name as a number (e.g., "1" becomes 1). If successful, it focuses that number. This allows clicking numerically named favorites even when their underlying workspace isn't currently active on the monitor (internal ID might be -1). If it's a non-numeric name ("web"), it currently logs a warning.

<!-- gh-comment-id:2817138346 --> @brickfrog commented on GitHub (Apr 20, 2025): Ah. Darn, turns out there's still some edge cases, the buttons for empty workspaces never get their workspace_id properly updated from the initial -1 value, so in a case where you have a map/favorites, it's still the same behavior (i.e., have a 1/2/3/4/5 in chinese, and, say, you're on 4, then you click 5 (empty), instead of going to 5 you go to 3) this ended up requiring edits to mod.rs in addition, but I think I mostly got it working - I can submit a PR if needed. - I didn't know if it was worth the temporary(?) bandaid or if this was more emblematic of how hyprland, etc. worked and was worth figuring that out **AI Notes:** **Problem**: Clicking workspace buttons, particularly "favorite" workspaces, was unreliable. Favorites start as placeholders (often with an internal ID of -1) and get linked to real workspace IDs when active. If the real workspace moved away, the favorite button might reset to -1 internally. The old code couldn't handle clicks correctly in these states because: It only sent numerical IDs, so clicking a placeholder (-1) or a named favorite ("web") failed. Even clicking a numerically named favorite ("1") could fail if its internal ID was reset to -1, as the system wasn't designed to focus based on the name "1". **Solution:** Introduced WorkspaceRequestMessage Enum: Created a message type that can carry either a workspace Id(i64) or a Name(String). Updated Controller: The controller now handles both message types. Id: Focuses the workspace ID directly. Name: Tries to parse the name as a number (e.g., "1" becomes 1). If successful, it focuses that number. This allows clicking numerically named favorites even when their underlying workspace isn't currently active on the monitor (internal ID might be -1). If it's a non-numeric name ("web"), it currently logs a warning.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
JakeStanger/ironbar#8713
No description provided.