Replace libappindicator with ksni

[dfaust]

Using ksni and the xdg standard for tray icons on Linux unlocks missing functionality and new features (#104 and more), as well as unblocks a GTK4 migration (tauri-apps/webkit2gtk-rs#94).

• Predefined menu items are not handled, except separator and about.
• Shortcuts are ignored.

Companion PR for muda:
Export more internals so muda can be used in combination with ksni: tauri-apps/muda#239

Tauri issue:
[feat] Use ksni crate for tray icons on Linux: tauri-apps/tauri#11293

[dfaust]

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

[FabianLars]

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

[amrbashir]

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

[FabianLars]

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.

[dfaust]

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

[amrbashir]

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

[dfaust]

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.

[FabianLars]

the macos issue should be fixed by #220

[dfaust]

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)

[samvv]

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.

[ancwrd1]

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

[rmakestrash-jpg]

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.

[dfaust]

@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.

[marc2332]

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

cc @amrbashir

[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.

[marc2332]

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.

[amrbashir]

I think they just remove the menu item from its parent menu and re-add it with new text.

I gave up on this idea quickly because changing a menu item title API is on MenuItem::set_text not Menu::set_child_text and so it would require children menu items to have reference to its parent, while parent also have reference to the child.

This also gets extra complicated because of how muda is written to allow:

• Cheap and easy cloning of a MenuItem backed by Rc. This is needed so other scenarios can work.
• Same menu item can be added to any number of menus.
• Same menu item can be added multiple times to the same menu.

I almost forgot someone tried custom gtk menu items here -> tauri-apps/muda#325

[marc2332]

I am just thinking in general, but this issue of not being able to update existing menu/menu item also happens in other languages/tools/whatever right? Or is it a gio-specific issue? (I am not entirely familiar with all this so hopefully I don't sound too dummy)

[rmakestrash-jpg]

@amrbashir anything i can do to help? sorry i haven't kept up with the 6 forks recently @marc2332 i tried to do as much as i could without overreaching on decisions like that so that's why this is where it is.

[amrbashir]

I am just thinking in general, but this issue of not being able to update existing menu/menu item also happens in other languages/tools/whatever right? Or is it a gio-specific issue?

Not sure what you mean by other languages/tools but this issue is a decision choice made by the gtk team in gtk4, it exists on all, nothing special to Rust.

However if you mean Windows and macOS, then they pretty much allow modifying exiting menu items on the fly. No issues there.

[amrbashir]

@amrbashir anything i can do to help? sorry i haven't kept up with the 6 forks recently @marc2332 i tried to do as much as i could without overreaching on decisions like that so that's why this is where it is.

I think I saw your fork a while back but you never opened a PR so I forgot about it for a while

I saw you went with remove and insert approach which is okay IMO. If you want please open a PR and I will help review, discuss and test the implementation.

[rmakestrash-jpg]

@amrbashir anything i can do to help? sorry i haven't kept up with the 6 forks recently @marc2332 i tried to do as much as i could without overreaching on decisions like that so that's why this is where it is.

I think I saw your fork a while back but you never opened a PR so I forgot about it for a while

I saw you went with remove and insert approach which is okay IMO. If you want please open a PR and I will help review, discuss and test the implementation.

i could be wrong but i believe i only posted the main PR out of respect to others who work i was building on and also because i believe the ecosystem needed the full ecosystem over to gtk4. it is possible i misunderstand been a minute since i looked at this.

tauri-apps/tauri#14684

[amrbashir]

There is no one working on migrations atm AFAIK. The reason no one looked at your tauri PR is because the rest of the ecosystem haven't migrated yet.

The migration process should be

muda -> tray ---\
tao -> wry ----> tauri

[rmakestrash-jpg]

There is no one working on migrations atm AFAIK. The reason no one looked at your tauri PR is because the rest of the ecosystem haven't migrated yet.

The migration process should be

muda -> tray ---\
tao -> wry ----> tauri

apologies i thought i did all of them, i did muda tao wry tauri tray am i missing something? i feel slow. sorry if im annoying i just would complete the work if i knew what was needed "I've commented on each upstream PR offering to help with integration testing:
tauri-apps/tao#1104 (comment), tauri-apps/wry#1530 (comment), tauri-apps/muda#272 (comment), #201 (comment)"

[amrbashir]

you just posted some comments, I can't discuss implementation in a comment, you'd need to open a PR so we I can properly review.