JakeStanger/ironbar

Fork 0

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

[GH-ISSUE #645] [Tray] iwgtk indicator fails to display and errors out ironbar #215

New issue

Closed

opened 2026-05-22 21:51:54 +01:00 by JakeStanger · 8 comments

JakeStanger commented

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

Owner

Originally created by @JonasVerhofste on GitHub (Jun 21, 2024).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/645

Describe the bug
When running iwgtk with indicator support, ironbar does not show the tray icon and throws an error. I'm pretty sure this is unrelated to other tray-related issues, as other tray applications work fine. Running with IRONBAR_LOG=debug gives me the following relevant output:

2024-06-20T23:41:31.183938Z DEBUG dispatch_message{msg=Msg { type: MethodCall, sender: UniqueName(Str(Borrowed(":1.172"))), path: ObjectPath("/StatusNotifierWatcher"), iface: InterfaceName(Str(Borrowed("org.kde.StatusNotifierWatcher"))), member: MemberName(Str(Borrowed("RegisterStatusNotifierItem"))), body: Signature("s") }}:dispatch_method_call{msg=Msg { type: MethodCall, sender: UniqueName(Str(Borrowed(":1.172"))), path: ObjectPath("/StatusNotifierWatcher"), iface: InterfaceName(Str(Borrowed("org.kde.StatusNotifierWatcher"))), member: MemberName(Str(Borrowed("RegisterStatusNotifierItem"))), body: Signature("s") }}:dispatch_method_call_try{msg=Msg { type: MethodCall, sender: UniqueName(Str(Borrowed(":1.172"))), path: ObjectPath("/StatusNotifierWatcher"), iface: InterfaceName(Str(Borrowed("org.kde.StatusNotifierWatcher"))), member: MemberName(Str(Borrowed("RegisterStatusNotifierItem"))), body: Signature("s") }}: system_tray::dbus::status_notifier_watcher: 73: registered item: org.kde.StatusNotifierItem-29555-1 | :1.172
2024-06-20T23:41:31.184169Z DEBUG system_tray::client: 127: received new item: :1.172org.kde.StatusNotifierItem-29555-1
2024-06-20T23:41:31.184358Z ERROR system_tray::client: 240: Error fetching properties from :1.172org.kde.StatusNotifierItem-29555-1/StatusNotifierItem: ServiceUnknown("The name is not activatable")

As far as I understand it (and I could be horribly wrong), the StatusNotifierItem API that is mentioned in the iwgtk README, is the freedesktop standard that the kde libappindicator protocol implements? So in theory, iwgtk and ironbar should be compatible?
However, I'm not sure if the above problem here lies with ironbar, a library used by ironbar or the way iwgtk advertises itself. In case of the latter two I'll create issues in the relevant repo and this can be closed.

To Reproduce

Install iwgtk: https://github.com/J-Lentz/iwgtk/ (Arch aur package iwgtk)
Start ironbar
Run iwgtk with tray support: iwgtk -i (or iwgtk --indicators)

Expected behavior
The iwgtk icon shows up in the tray

System information:

Distro: Arch Linux
Compositor: Hyprland v0.41.1
Ironbar version: git main (a9d728f191 at the time of writing)

Originally created by @JonasVerhofste on GitHub (Jun 21, 2024). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/645 **Describe the bug** When running [iwgtk](https://github.com/J-Lentz/iwgtk/) with indicator support, ironbar does not show the tray icon and throws an error. I'm pretty sure this is unrelated to other tray-related issues, as other tray applications work fine. Running with `IRONBAR_LOG=debug` gives me the following relevant output: ``` 2024-06-20T23:41:31.183938Z DEBUG dispatch_message{msg=Msg { type: MethodCall, sender: UniqueName(Str(Borrowed(":1.172"))), path: ObjectPath("/StatusNotifierWatcher"), iface: InterfaceName(Str(Borrowed("org.kde.StatusNotifierWatcher"))), member: MemberName(Str(Borrowed("RegisterStatusNotifierItem"))), body: Signature("s") }}:dispatch_method_call{msg=Msg { type: MethodCall, sender: UniqueName(Str(Borrowed(":1.172"))), path: ObjectPath("/StatusNotifierWatcher"), iface: InterfaceName(Str(Borrowed("org.kde.StatusNotifierWatcher"))), member: MemberName(Str(Borrowed("RegisterStatusNotifierItem"))), body: Signature("s") }}:dispatch_method_call_try{msg=Msg { type: MethodCall, sender: UniqueName(Str(Borrowed(":1.172"))), path: ObjectPath("/StatusNotifierWatcher"), iface: InterfaceName(Str(Borrowed("org.kde.StatusNotifierWatcher"))), member: MemberName(Str(Borrowed("RegisterStatusNotifierItem"))), body: Signature("s") }}: system_tray::dbus::status_notifier_watcher: 73: registered item: org.kde.StatusNotifierItem-29555-1 | :1.172 2024-06-20T23:41:31.184169Z DEBUG system_tray::client: 127: received new item: :1.172org.kde.StatusNotifierItem-29555-1 2024-06-20T23:41:31.184358Z ERROR system_tray::client: 240: Error fetching properties from :1.172org.kde.StatusNotifierItem-29555-1/StatusNotifierItem: ServiceUnknown("The name is not activatable") ``` As far as I understand it (and I could be horribly wrong), the `StatusNotifierItem API` that is mentioned in the iwgtk README, is the freedesktop standard that the kde libappindicator protocol implements? So in theory, iwgtk and ironbar should be compatible? However, I'm not sure if the above problem here lies with ironbar, a library used by ironbar or the way iwgtk advertises itself. In case of the latter two I'll create issues in the relevant repo and this can be closed. **To Reproduce** - Install iwgtk: https://github.com/J-Lentz/iwgtk/ (Arch aur package [iwgtk](https://aur.archlinux.org/packages/iwgtk)) - Start ironbar - Run iwgtk with tray support: `iwgtk -i` (or `iwgtk --indicators`) **Expected behavior** The iwgtk icon shows up in the tray **System information:** - Distro: Arch Linux - Compositor: Hyprland v0.41.1 - Ironbar version: git main (a9d728f1911007afa1edf6aac2ca1148b4c22d6c at the time of writing)

JakeStanger closed this issue

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

JakeStanger commented

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

Author

Owner

@JakeStanger commented on GitHub (Jun 28, 2024):

However, I'm not sure if the above problem here lies with ironbar, a library used by ironbar or the way iwgtk advertises itself. In case of the latter two I'll create issues in the relevant repo and this can be closed.

I've not investigated yet, but here's what I do know:

The protocol is AWFUL. Absolutely dreadful, poorly defined, and every implementation varies.
Ironbar's implementation is not entirely spec-compliant. There's a few weird edge cases I need to sort, which is causing a lot of the reported tray issues.

My litmus test tends to be "does it work properly in another tray impl?" For example, all of Waybar, AGS and Quickshell have more correct implementations. A tray icon's behaviour there will confirm whether it's Ironbar or not.

@JakeStanger commented on GitHub (Jun 28, 2024): > However, I'm not sure if the above problem here lies with ironbar, a library used by ironbar or the way iwgtk advertises itself. In case of the latter two I'll create issues in the relevant repo and this can be closed. I've not investigated yet, but here's what I do know: - The protocol is AWFUL. Absolutely dreadful, poorly defined, and every implementation varies. - Ironbar's implementation is not entirely spec-compliant. There's a few weird edge cases I need to sort, which is causing a lot of the reported tray issues. My litmus test tends to be "does it work properly in another tray impl?" For example, all of Waybar, AGS and Quickshell have more correct implementations. A tray icon's behaviour there will confirm whether it's Ironbar or not.

JakeStanger commented

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

Author

Owner

@JonasVerhofste commented on GitHub (Jun 28, 2024):

Installed waybar to test and can confirm that it seems to work properly there (including changing icon images depending on wifi state). So that sadly increases the odds of it being ironbar.

I'll see if I can figure out where exactly it goes wrong. My brain however doesn't fully agree with rust (yet), so it'll take a bit for my head to wrap around the issue.

@JonasVerhofste commented on GitHub (Jun 28, 2024): Installed waybar to test and can confirm that it seems to work properly there (including changing icon images depending on wifi state). So that sadly increases the odds of it being ironbar. I'll see if I can figure out where exactly it goes wrong. My brain however doesn't fully agree with rust (yet), so it'll take a bit for my head to wrap around the issue.

JakeStanger commented

2026-05-22 21:51:55 +01:00

Author

Owner

@JakeStanger commented on GitHub (Jun 28, 2024):

No worries if you can't get anywhere, it's not an easy task. If you do want to give it a go though, the tray impl is here: https://github.com/JakeStanger/system-tray

@JakeStanger commented on GitHub (Jun 28, 2024): No worries if you can't get anywhere, it's not an easy task. If you do want to give it a go though, the tray impl is here: https://github.com/JakeStanger/system-tray

JakeStanger commented

2026-05-22 21:51:55 +01:00

Author

Owner

@JonasVerhofste commented on GitHub (Jun 28, 2024):

Aha, that's what I was missing! Not being used to the rust ecosystem I had not seen that the implementation lived elsewhere.
You want me to close this issue and create one there?

@JonasVerhofste commented on GitHub (Jun 28, 2024): Aha, that's what I was missing! Not being used to the rust ecosystem I had not seen that the implementation lived elsewhere. You want me to close this issue and create one there?

JakeStanger commented

2026-05-22 21:51:55 +01:00

Author

Owner

@JakeStanger commented on GitHub (Jun 29, 2024):

Happy to keep it here

@JakeStanger commented on GitHub (Jun 29, 2024): Happy to keep it here

JakeStanger commented

2026-05-22 21:51:55 +01:00

Author

Owner

@bwidawsk commented on GitHub (Jul 22, 2024):

I have little clue how dbus works but I took a look at this because I'd also like this functionality. I learned two small pieces of information

If you run ironbar AND THEN waybar, iwgtk -i will not work properly. Like ironbar changes the name or consumes the event first??
The destination/path seems to be messed up because there is no separator between the bus and the path (ie. I think a . is missing). I did fix this but it didn't actually improve anything.

Here is a poor implementation to fix the second one. I'm happy to actually fix this properly, I just don't want to learn the dbus stuff :)

diff --git a/src/client.rs b/src/client.rs
index 6a17554b5d0e..4554bb7d0314 100644
--- a/src/client.rs
+++ b/src/client.rs
@@ -7,7 +7,6 @@ use crate::error::Error;
 use crate::item::{self, Status, StatusNotifierItem};
 use crate::menu::TrayMenu;
 use dbus::DBusProps;
-use std::borrow::Cow;
 use std::collections::HashMap;
 use std::sync::{Arc, Mutex};
 use std::time::{SystemTime, UNIX_EPOCH};
@@ -172,11 +171,14 @@ impl Client {
         tx: broadcast::Sender<Event>,
         items: Arc<Mutex<State>>,
     ) -> crate::error::Result<()> {
-        let (destination, path) = address
-            .split_once('/')
-            .map_or((address, Cow::Borrowed("/StatusNotifierItem")), |(d, p)| {
-                (d, Cow::Owned(format!("/{p}")))
-            });
+        let org_ndx = address.find("org").unwrap();
+
+        let mut destination = address.to_owned();
+        let path = destination.split_off(org_ndx);
+        let separator: &str = &path[3..4];
+        let destination = destination.trim_end_matches(['/', '.']);
+        let path = format!("{}{}", separator, path);
+        let path = path.replace(".", "/");
 
         let properties_proxy = PropertiesProxy::builder(&connection)
             .destination(destination.to_string())?
@@ -184,7 +186,7 @@ impl Client {
             .build()
             .await?;
 
-        let properties = Self::get_item_properties(destination, &path, &properties_proxy).await?;
+        let properties = Self::get_item_properties(&destination, &path, &properties_proxy).await?;
 
         items
             .lock()

@bwidawsk commented on GitHub (Jul 22, 2024): I have little clue how dbus works but I took a look at this because I'd also like this functionality. I learned two small pieces of information 1. If you run ironbar AND THEN waybar, `iwgtk -i` will not work properly. Like ironbar changes the name or consumes the event first?? 2. The destination/path seems to be messed up because there is no separator between the bus and the path (ie. I think a . is missing). I did fix this but it didn't actually improve anything. Here is a poor implementation to fix the second one. I'm happy to actually fix this properly, I just don't want to learn the dbus stuff :) ```diff diff --git a/src/client.rs b/src/client.rs index 6a17554b5d0e..4554bb7d0314 100644 --- a/src/client.rs +++ b/src/client.rs @@ -7,7 +7,6 @@ use crate::error::Error; use crate::item::{self, Status, StatusNotifierItem}; use crate::menu::TrayMenu; use dbus::DBusProps; -use std::borrow::Cow; use std::collections::HashMap; use std::sync::{Arc, Mutex}; use std::time::{SystemTime, UNIX_EPOCH}; @@ -172,11 +171,14 @@ impl Client { tx: broadcast::Sender<Event>, items: Arc<Mutex<State>>, ) -> crate::error::Result<()> { - let (destination, path) = address - .split_once('/') - .map_or((address, Cow::Borrowed("/StatusNotifierItem")), |(d, p)| { - (d, Cow::Owned(format!("/{p}"))) - }); + let org_ndx = address.find("org").unwrap(); + + let mut destination = address.to_owned(); + let path = destination.split_off(org_ndx); + let separator: &str = &path[3..4]; + let destination = destination.trim_end_matches(['/', '.']); + let path = format!("{}{}", separator, path); + let path = path.replace(".", "/"); let properties_proxy = PropertiesProxy::builder(&connection) .destination(destination.to_string())? @@ -184,7 +186,7 @@ impl Client { .build() .await?; - let properties = Self::get_item_properties(destination, &path, &properties_proxy).await?; + let properties = Self::get_item_properties(&destination, &path, &properties_proxy).await?; items .lock() ```

JakeStanger commented

2026-05-22 21:51:56 +01:00

Author

Owner

@JakeStanger commented on GitHub (Nov 6, 2024):

Hello, I'm finally looking at picking this up. Unfortunately I can't even get iwgtk to start at the minute.

The above patch only works if the address has org in it, which a lot don't, causing it to crash. I'm sure it's a good start though, so as soon as I can get the thing to work I'll see if I can work it into the code.

@JakeStanger commented on GitHub (Nov 6, 2024): Hello, I'm finally looking at picking this up. Unfortunately I can't even get `iwgtk` to start at the minute. The above patch only works if the address has `org` in it, which a lot don't, causing it to crash. I'm sure it's a good start though, so as soon as I can get the thing to work I'll see if I can work it into the code.

JakeStanger commented

2026-05-22 21:51:56 +01:00

Author

Owner

@MTSYuki commented on GitHub (Jun 19, 2025):

Hello, I use iwgtk tray on Ironbar and I noticed when launching the bar AND then iwgtk, the icon don't show and appears this message
ERROR system_tray::client: 183: zbus variant error
I not sure why this happens, but I know is something on Ironbar, bc this works on Waybar

@MTSYuki commented on GitHub (Jun 19, 2025): Hello, I use iwgtk tray on Ironbar and I noticed when launching the bar AND then iwgtk, the icon don't show and appears this message `ERROR system_tray::client: 183: zbus variant error` I not sure why this happens, but I know is something on Ironbar, bc this works on Waybar

JakeStanger referenced this issue

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

[PR #215] [MERGED] build(deps): bump clap from 4.3.4 to 4.3.10 #554

JakeStanger referenced this issue

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

[PR #215] [MERGED] build(deps): bump clap from 4.3.4 to 4.3.10 #1962

JakeStanger referenced this issue

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

[PR #215] [MERGED] build(deps): bump clap from 4.3.4 to 4.3.10 #3368

JakeStanger referenced this issue

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

[PR #215] [MERGED] build(deps): bump clap from 4.3.4 to 4.3.10 #4773