JakeStanger/ironbar

Fork 0

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

[GH-ISSUE #1279] `tray` module does not update icons #386

New issue

Closed

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

JakeStanger commented

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

Owner

Originally created by @ejrichards on GitHub (Dec 17, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1279

Describe the bug
Tray icons do not update, eg when an application updates its icon to display that a notification is available.

To reproduce
Steps to reproduce the behavior:

Add module tray
Open a program that updates its tray icon, for example, Discord
When there are unread messages, the tray icon does not update

Expected behavior
A red dot should appear. This also occurs with Zulip, which updates the icon to be the number of unread messages.

System information:

Distro: NixOS
Ironbar version: nixpkgs 0.17.1 and main

Configuration

Config

[[end]]
type = "tray"

Styles

Occurs with no CSS styling

Log error every time an update should happen

WARN system_tray::client: 459: Error getting IconName: ZBusFdo(Failed("error occurred in Get"))

This is also in the logs, although I'm not sure if it is relevant

WARN system_tray::client: 469: org.freedesktop.DBus.Error.InvalidArgs: No such property “IconPixmap”

Originally created by @ejrichards on GitHub (Dec 17, 2025). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1279 **Describe the bug** Tray icons do not update, eg when an application updates its icon to display that a notification is available. **To reproduce** Steps to reproduce the behavior: 1. Add module `tray` 2. Open a program that updates its tray icon, for example, Discord 3. When there are unread messages, the tray icon does not update **Expected behavior** A red dot should appear. This also occurs with Zulip, which updates the icon to be the number of unread messages. **System information:** - Distro: NixOS - Ironbar version: nixpkgs 0.17.1 and main **Configuration** <details><summary>Config</summary> ```toml [[end]] type = "tray" ``` </details> <details><summary>Styles</summary> Occurs with no CSS styling </details> Log error every time an update should happen ``` WARN system_tray::client: 459: Error getting IconName: ZBusFdo(Failed("error occurred in Get")) ``` This is also in the logs, although I'm not sure if it is relevant ``` WARN system_tray::client: 469: org.freedesktop.DBus.Error.InvalidArgs: No such property “IconPixmap” ```

JakeStanger

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

closed this issue
added the
A:UX/UI

M:Tray

T:Bug

P:Low
labels

JakeStanger commented

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

Author

Owner

@JakeStanger commented on GitHub (Dec 17, 2025):

I've observed this myself, and it seems to be a problem with Electron having some bogus implementation of the SNI protocol. I think (need to confirm) Plasma handles it correctly, so presumably there is a workaround.

@JakeStanger commented on GitHub (Dec 17, 2025): I've observed this myself, and it seems to be a problem with Electron having some bogus implementation of the SNI protocol. I _think_ (need to confirm) Plasma handles it correctly, so presumably there is a workaround.

JakeStanger commented

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

Author

Owner

@Windblows2000 commented on GitHub (Dec 18, 2025):

I tried taking look at it for a cheap fix. It seems that the implementation is indeed inconsistent between the different applications. I tried LM Studio, Vesktop (dont have the official Discord client so I cant confirm it), and Cachy-Update. Each did throw a different failure that made it impossible to update the icon. LM Studio sent an icon_name None, while Vesktop couldn't even send one over zbus.

A redraw if either the name or pixmap data change seems to do the trick. Though I'm unsure how that affects performance (Cachy-Update shot 4 icon updates at once.)

// src/modules/tray/mod.rs

UpdateEvent::Icon {
    icon_name,
    icon_pixmap,
} => {
    let name_changed = icon_name.as_ref() != menu_item.icon_name();
    let pixmap_changed = icon_pixmap != menu_item.icon_pixmap;

    if name_changed || pixmap_changed {
        menu_item.icon_pixmap = icon_pixmap;
        menu_item.set_icon_name(icon_name);

        match icon::get_image(
            menu_item,
            icon_config.size,
            icon_config.prefer_theme,
            &icon_config.theme,
        ) {
            Ok(image) => menu_item.set_image(&image),
            Err(e) => {
                error!("error loading icon: {e}");
                menu_item.show_label();
            }
        }
    }
}

@Windblows2000 commented on GitHub (Dec 18, 2025): I tried taking look at it for a cheap fix. It seems that the implementation is indeed inconsistent between the different applications. I tried LM Studio, Vesktop (dont have the official Discord client so I cant confirm it), and Cachy-Update. Each did throw a different failure that made it impossible to update the icon. LM Studio sent an icon_name None, while Vesktop couldn't even send one over zbus. A redraw if either the name or pixmap data change seems to do the trick. Though I'm unsure how that affects performance (Cachy-Update shot 4 icon updates at once.) ```rs // src/modules/tray/mod.rs UpdateEvent::Icon { icon_name, icon_pixmap, } => { let name_changed = icon_name.as_ref() != menu_item.icon_name(); let pixmap_changed = icon_pixmap != menu_item.icon_pixmap; if name_changed || pixmap_changed { menu_item.icon_pixmap = icon_pixmap; menu_item.set_icon_name(icon_name); match icon::get_image( menu_item, icon_config.size, icon_config.prefer_theme, &icon_config.theme, ) { Ok(image) => menu_item.set_image(&image), Err(e) => { error!("error loading icon: {e}"); menu_item.show_label(); } } } } ```

JakeStanger commented

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

Author

Owner

@JakeStanger commented on GitHub (Dec 18, 2025):

The best test-case for performance would be nm-applet. Disabling and enabling the adaptor will cause it to re-connect, which should show an animation. Each animation frame is sent as an icon update. That should work, at least...

So long as the menu itself isn't re-rendered, it should be cheap enough.

@JakeStanger commented on GitHub (Dec 18, 2025): The best test-case for performance would be `nm-applet`. Disabling and enabling the adaptor will cause it to re-connect, which should show an animation. Each animation frame is sent as an icon update. That should work, at least... So long as the menu itself isn't re-rendered, it should be cheap enough.

JakeStanger commented

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

Author

Owner

@Windblows2000 commented on GitHub (Dec 18, 2025):

Thank you for the response.

Just tested nm-applet by reconnecting to the network. The logic seems solid. It correctly captures the animation frames while avoiding duplicates. the check name_changed || pixmap_changed makes sure of that.

@Windblows2000 commented on GitHub (Dec 18, 2025): Thank you for the response. Just tested ```nm-applet``` by reconnecting to the network. The logic seems solid. It correctly captures the animation frames while avoiding duplicates. the check ```name_changed || pixmap_changed``` makes sure of that.

JakeStanger commented

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

Author

Owner

@JakeStanger commented on GitHub (Dec 18, 2025):

Cool in that case if you want to submit a PR I can get that turned around pretty quick for you

@JakeStanger commented on GitHub (Dec 18, 2025): Cool in that case if you want to submit a PR I can get that turned around pretty quick for you

JakeStanger referenced this issue

2026-05-22 21:54:16 +01:00

[PR #386] [MERGED] build(deps): bump tokio from 1.35.0 to 1.35.1 #680

JakeStanger referenced this issue

2026-05-22 22:55:48 +01:00

[PR #386] [MERGED] build(deps): bump tokio from 1.35.0 to 1.35.1 #2086

JakeStanger referenced this issue

2026-05-22 23:55:57 +01:00

[PR #386] [MERGED] build(deps): bump tokio from 1.35.0 to 1.35.1 #3494

JakeStanger referenced this issue

2026-05-23 00:55:44 +01:00

[PR #386] [MERGED] build(deps): bump tokio from 1.35.0 to 1.35.1 #4899