tauri-apps
[feat] Use ksni crate for tray icons on Linux
Describe the problem
Currently Tauri uses libappindicator to create tray icons on Linux. But it has far fewer features than the xdg standard, as well as macOS and Windows. There are multiple bug reports and feature requests regarding tray icon issues on Linux. In particular it's not possible to handle left clicks and to add tool tips.
Describe the solution you'd like
I would like to use the xdg standard for tray icons, which is supported on all Linux desktop environments and has many more features than libappindicator. Also libappindicator looks pretty dead. The last commit to the src folder is 15 years old. https://bazaar.launchpad.net/~indicator-applet-developers/libappindicator/trunk/files
It looks to me like https://github.com/iovxw/ksni is a great fit for this task. It should be fairly easy to integrate it into Tauri.
I'm ready to write the necessary code myself. I just want to know if you are interested in merging it and if you would like to keep libappindicator as a choice, or if I can remove it.
Alternatives considered
No response
Additional context
No response
Yes, this is desirable, see https://github.com/tauri-apps/tray-icon/issues/107 and https://github.com/tauri-apps/tray-icon/issues/104 for example.
It should be fairly easy to integrate it into Tauri.
Probably yeah, the only thing i'm not sure how to best approach is the inter-op with muda.
Ok, great. Sounds like you would like to remove libappindicator as well. I'll start working on it then.
@FabianLars: Integrating it with muda really is a pain. After a few iterations of shoehorning it in, I came up with the following changes. Please have a look at them. If you don't have any major concerns, I will update the docs and create the merge requests.
https://github.com/tauri-apps/tray-icon/compare/dev...dfaust:tray-icon:ksni
https://github.com/tauri-apps/muda/compare/dev...dfaust:muda:ksni
Let me pull in @amrbashir the maintainer of the crates in question. I'll still try to take a look myself but i'm still out sick so idk when i can get to it.
@dfaust thank you for the hard work, this looks very promising, please feel free to open the PRs and we will discuss the finer details
I have no problem with migrating to ksni, but have you considered libayatana-appindicator, which is supposed to be a GTK-free continuation of libappindicator? https://github.com/AyatanaIndicators/libayatana-appindicator-glib
we're using the "old" version that still relied on gtk in conjunction with libappindicator because both libayatana-appindicator and libappindicator aren't available on all distros (together they are covering all though).
the new -glib version would be interesting since it should work together with gtk4 but it's not available in any distro yet (except debian unstable) as far as i can tell and it also has the same feature set so stuff like onclick events are still missing. Since the ksni PR(s) are already in a pretty good state i don't think it's worth to look into this new version.
FYI — I’ve tested the ksni implementation downstream. It works well on KDE, but the tray menu fails to render correctly on GNOME, despite multiple attempts.
Since GNOME has not actively supported SNI (StatusNotifierItem) since Shell 3.26, adopting ksni could negatively affect GNOME users.
Side note: I also experimented with tray onclick handling in ksni (commit link), but the main rendering issue on GNOME remains unresolved.
but the tray menu fails to render correctly on GNOME, despite multiple attempts.
Can you expand on that a bit? Does it look "wrong" or is there simply nothing at all?
Since GNOME has not actively supported SNI (StatusNotifierItem) since Shell 3.26, adopting ksni could negatively affect GNOME users.
Well, same for libappindicator. Gnome doesn't support any kind of tray implementation directly.
Can you expand on that a bit? Does it look "wrong" or is there simply nothing at all?
The system tray icon displays correctly, but the tray menu does not render at all. The only tray interaction that works is double-clicking the icon to open the main application window; all other tray operations do not respond.
Well, same for libappindicator. Gnome doesn't support any kind of tray implementation directly.
Although GNOME does not provide native system tray support, libappindicator can be more reliable than ksni in certain GNOME configurations. With compatibility extensions (e.g., the AppIndicator extension), some applications can display icons and menus, though functionality is not guaranteed. To improve tray menu visibility and interaction in GNOME, using libappindicator as a fallback where ksni alone is insufficient may be a viable approach.
The system tray icon displays correctly, but the tray menu does not render at all. The only tray interaction that works is double-clicking the icon to open the main application window; all other tray operations do not respond.
Hmm, interesting. I'd imagine that this should be fixable as we're not the first one to use sni on gnome. Would you mind repeating this part of the comment in the PR as well? :)
(e.g., the AppIndicator extension)
which is also what implements sni support.
using libappindicator as a fallback
I agree that this would be nice but i don't think it's feasible when we're trying to drop gtk3 here 🤔
I've shared what I found here. Feel free to reference this in the PR if needed. I'm just a downstream user providing testing feedback.
The system tray icon displays correctly, but the tray menu does not render at all. The only tray interaction that works is double-clicking the icon to open the main application window; all other tray operations do not respond.
Hello, I'm the author of ksni.
This is a bit awkward, but I'm actually a GNOME user myself — most of ksni's development has been done on GNOME. So I'm quite surprised to hear it's not working properly in that environment.
Could you please share more details to help me reproduce the problem?
I also noticed this commit: https://github.com/clash-verge-rev/ksni/commit/c1cf3b3e58394f5463197bd8da6fd6dc3afbccb4. However, to my knowledge, ubuntu/gnome-shell-extension-appindicator doesn’t behave this way. If you're using a different extension or a fork, that information would be very helpful.
@iovxw Thanks for your reply. I’m not using GNOME at the moment, but looking back, I think there might have been some issues with my implementation when I was using ksni. The commit https://github.com/clash-verge-rev/ksni/commit/c1cf3b3e58394f5463197bd8da6fd6dc3afbccb4 was just an early attempt. Right now, I’m leaning toward using ksni instead of libappindicator in Tauri.
Thanks again for your work on ksni!