mirror of
https://github.com/JakeStanger/ironbar.git
synced 2026-07-11 08:15:21 +01:00
[GH-ISSUE #938] name_map/favorites navigation error #1691
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#1691
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 @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.
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
@JakeStanger commented on GitHub (Apr 15, 2025):
Thanks for reporting. Do you get any error/warning logs out when you click and nothing happens?
@brickfrog commented on GitHub (Apr 15, 2025):
Hmm, not that I see:
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)
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.
@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:
@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_tagandget_tagon the button widget itself. That avoids the need to wrap code inRc<RefCell<T>>which might make things a little neater.@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.