mirror of
https://github.com/JakeStanger/ironbar.git
synced 2026-07-11 06:15:21 +01:00
[GH-ISSUE #1404] Tray icon for FlClash (Flutter-based) fails to update #4640
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#4640
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 @ffs-akl on GitHub (Feb 28, 2026).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1404
Describe the bug
The tray icon for FlClash (a Flutter-based VPN/Proxy client) is not displayed correctly in Ironbar's tray module. While other status bar implementations like sfwbar handle it perfectly, Ironbar shows a generic icon or a placeholder that never changes.
Crucial Observation: Dynamic Status Icons
FlClash has 3 distinct status icons representing different connection states. These icons are stored as absolute paths in the application's data directory:
In sfwbar, the icon correctly switches between these three images in real-time. In Ironbar, it never displays the actual icon from these paths, nor does it react to state changes.
To reproduce
Steps to reproduce the behavior:
trayExpected behavior
Ironbar should resolve the absolute file paths provided by the StatusNotifierItem (SNI) protocol and update the icon immediately when the application signals a change.
System information:
Configuration
Config
Styles
Additional context
output message form terminal
2026-02-28T02:26:58.819242Z INFO system_tray::dbus::status_notifier_watcher: 141: new item: :1.439/StatusNotifierItem 2026-02-28T02:26:58.821329Z INFO system_tray::dbus::status_notifier_watcher: 137: new item: :1.363/org/ayatana/NotificationItem/nm_applet (duplicate) 2026-02-28T02:27:32.711049Z WARN system_tray::client: 469: org.freedesktop.DBus.Error.InvalidArgs: No such property 'IconPixmap' 2026-02-28T02:27:32.711226Z WARN system_tray::client: 469: org.freedesktop.DBus.Error.InvalidArgs: No such property 'IconPixmap' 2026-02-28T02:27:38.708938Z WARN system_tray::client: 469: org.freedesktop.DBus.Error.InvalidArgs: No such property 'IconPixmap'@JakeStanger commented on GitHub (Apr 14, 2026):
Could you see if the latest commit fixes this please? I've just merged #1221 which improves support of image handling for the tray so that it now goes through the central system.
@ffs-akl commented on GitHub (Apr 16, 2026):
in git ver
a59bb56,I did some further testing and confirmed that the issue is specifically about the dynamic update of IconPixmap.Here is the behavior I observed:
Initial Load is Fine: When ironbar starts, it correctly grabs and displays the current tray icon from FLClash (e.g., status_1).
Dynamic Update Fails: When FLClash changes its state (e.g., from status_1 to status_2), the icon in ironbar immediately turns into a "missing-image" (circle-slash) placeholder.
Logs confirm the failure: Every time the icon tries to update, ironbar throws:
WARN system_tray::client: org.freedesktop.DBus.Error.InvalidArgs: No such property “IconPixmap”
Proof of Initialization Success: If I restart ironbar after the icon has already changed to status_2, it will correctly display status_2 upon startup. But as soon as it switches back to status_1, it breaks again.
It seems ironbar can fetch the pixmap during the initial scan but fails to do so during an incremental update.
https://github.com/user-attachments/assets/d8476f50-0cc9-40ea-80e7-3a65c8ef5a8b
@JakeStanger commented on GitHub (May 8, 2026):
This was such a weird issue in the end. It doesn't help that FLClash doesn't implement a spec-compliant icon tray (nothing does, awful spec, blah blah), but basically the pixmap warning was not the issue (and that'll continue to get logged until they fix their tray).
Ironbar was properly receiving the icon path, properly rendering it and loading it into the image, and then...effectively throwing it away. There was a call to GTK to set the icon on the tray icon button, which it turns out rips out the widget tree and sticks its own in.
The only reason I'd not spotted it before is because every other tray icon either sends a pixmap or an icon name rather than a file path (like the spec says you should...), so GTK handled the icons fine.
Fix incoming shortly!