@amrbashir @FabianLars How do we proceed from here? The tests fail because the PR depends on tauri-apps/muda#239.

you can make tray-icon depend on the git version of muda for now

Sorry for the delay, been a bit busy IRL, and also not sure if we want to have this in tauri v2, keep old implementation and add it in tauri v2 behind a feature flag or wait for v3

if we make v3 only about switching from gtk3 to gtk4 (which imo we should) this change could wait for v3. If v3 takes ages i think it would be better to add it in v2 if that's not too much of a headache. I wouldn't put it behind a feature flag either way unless there's something missing compared to the libappindicator implementation that i don't see rn.

Alright. Then please keep me updated.
And I updated the muda dependency.

I am actually leaning towards keeping the old implementation for now and adding this behind experimental feature flag (ksni) for both, tray-icon crate and tauri crate

I put the ksni stuff behind a feature flag linux-ksni (I also renamed the muda feature).

I also created a new PR for tauri (tauri-apps/tauri#12319).

And it seems the compiler has become more strict. I'm still fixing the windows issues. The macos issue I don't understand, though.

the macos issue should be fixed by #220

I rebased the PR, but now the about dialog crashes:

cargo run --example tao -F linux-ksni

(tao:1924160): Gtk-CRITICAL **: 14:46:21.228: gtk_text_attributes_ref: assertion 'values != NULL' failed

(tao:1924160): Gtk-CRITICAL **: 14:46:21.228: gtk_text_attributes_ref: assertion 'values != NULL' failed

(tao:1924160): Pango-CRITICAL **: 14:46:21.228: pango_layout_new: assertion 'context != NULL' failed
Speicherzugriffsfehler (Speicherabzug geschrieben)

Is there anything preventing this issue from being merged? I'm happy to help but I don't know what still needs to be done.

That is a very interesting PR, any plans to finish it?

Hey @dfaust! Thanks for the KSNI implementation work - this is exactly what we needed for proper Linux system tray support.

My tray-icon fork: https://github.com/rmakestrash-jpg/tray-icon/tree/feat/gtk4

Changes on top of your work:

• Made linux-ksni the default feature for modern Linux support
• Added appindicator as an optional GTK3 legacy fallback
• Updated for GTK4 compatibility with our muda-fork
• Merged upstream and resolved conflicts
• Added auto-sync workflow to stay current with upstream
• Tested on Wayland for our Tauri app

This is part of a full GTK4 stack we're putting together:

• tao: fix(linux): Port to gtk4-rs tao#1104
• wry: fix(linux): Port to webkitgtk6 wry#1530

Tested on Wayland and everything works great!

I used Claude to help with this. Would really appreciate if you could review when you get a chance.

@rmakestrash-jpg Sorry for not replying earlier. I meant to look at your code, but I just don't have the mental capacity for it right now. Glad to see that my work was not in vain. I hope your PRs will succeeded.

Is there anything blocking this? I want to help moving this forward

cc @amrbashir

@marc2332 This is blocked on the whole gtk migration through the tauri ecosystem, currently the biggest blocker was muda, the APIs have changed drastically and I had to rewrite from scratch.

My progress can be found here tauri-apps/muda#272 .

I have hit a wall there when I realized gio::Menu can't be changed after creation which meant things like MenuItem::set_title API can't be implemented. You have to keep track of the whole gio::Menu tree and when you want to change an item inside it, you recreate a new gio::Menu from scratch.

This means I have to look for a different approach, probably implementing custom gtk Menu and MenuItem widgets the implement MenuModel interface.

The next big thing would be moving tao to a winit-gtk crate, but only muda is blocking tray-icon crate. Other ecosystem changes can follow.

custom gtk Menu and MenuItem widgets the implement MenuModel interface.

That certainly sounds a bit too complicated

as a random idea, would it be less crazy to implement some sort of diffing system that get queued and upon certain event loop tick all those queued diffs are diffed and some menus and items are recreated accordingly? Maybe this is also a bit too complicated.

If this is how it works in gtk4, I wonder what do people usually do.