Create system tray guide

[StepanZagray]

This is a guide on how to add system tray for your app in tauri v2 based on this issue. I changed code from there so it works on newest version v2.0.0-beta.24. I would like someone more experienced to maybe add descriptions and explanations, I don't really know what to write, especially in "Creating a system tray" section.

[netlify[bot]]

✅ Deploy Preview for tauri-v2 ready!

Name	Link
🔨 Latest commit	7b9e63f415cd3127893b523fb53912bb924682d1
🔍 Latest deploy log	https://app.netlify.com/sites/tauri-v2/deploys/66d6fd51f06f0c0008a6ce3d
😎 Deploy Preview	https://deploy-preview-2428--tauri-v2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 98 (🔴 down 2 from production) Accessibility: 100 (no change from production) Best Practices: 100 (no change from production) SEO: 92 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[StepanZagray]

Also want to note that I tested this code only on windows. I am not sure if macOS functionality works

[vasfvitor]

hey, thanks for this. Notice that /plugins pages has very specific structure for plugin workspace plguins. System tray isn't a plugin in this sense. So I think this should go perhaps in /develop? What do you think?

[vasfvitor]

I would like someone more experienced to maybe add descriptions and explanations, I don't really know what to write, especially in "Creating a system tray" section.

for starters you can try code comments (if any) where you feel necessary, like a bit of context about what it does, or why

[StepanZagray]

hey, thanks for this. Notice that /plugins pages has very specific structure for plugin workspace plguins. System tray isn't a plugin in this sense. So I think this should go perhaps in /develop? What do you think?

My decision was based on the fact that Window customization guide was in plugins section. I am new here, so I think you probably know better where it needs to be. Maybe move all guides in plugin section that are not "downloadable" plugins, into develop?

Also, system tray feature is not fully developed in v2, I couldn't find anything related to "System tray menu", so I assume right now there is no way to create menu. This might mean that in the future system tray will get it's own plugin with all features.

I want to say that all this are only my thoughts, and I don't know plans of tauri team.

[FabianLars]

It supports menus already (assuming you mean menus that pop up on click on the icon), see for example https://github.com/tauri-apps/tauri/blob/dev/examples/api/src-tauri/src/tray.rs - it re-uses the same Menu apis that are used for Window menus and Context menus.

[StepanZagray]

It supports menus already (assuming you mean menus that pop up on click on the icon), see for example https://github.com/tauri-apps/tauri/blob/dev/examples/api/src-tauri/src/tray.rs - it re-uses the same Menu apis that are used for Window menus and Context menus.

Oh, okay. Then I will work on minimal example of tray menu and add it here. \

By the way, what do you think about moving window customization, this guide and other guides that are not "downloadable plugins" to develop?

[FabianLars]

By the way, what do you think about moving window customization, this guide and other guides that are not "downloadable plugins" to develop?

Well, window customization (and the tray) are indeed not plugins in the traditional sense (they partially are in tauri's codebase) so should be moved. The develop section is currently our catch-all category so that'd be fine for now, thanks :)

Edit: window customization could also fit into the Learn function but i'll leave that to Simon and others.

[StepanZagray]

I will move all "not plugins" to develop in seperate pull request, after this one is merged. Maybe there are some requests or suggestions to this one? Maybe add or edit something. Also I would like someone to test this code on macOS

[StepanZagray]

Honestly, I am editing files on github itself. Maybe that's the problem? I mean github editor doesn't auto format

[FabianLars]

I feel like the example is a bit extreme. I think it should be more basic for the docs.

[StepanZagray]

I feel like the example is a bit extreme. I think it should be more basic for the docs.

Maybe add 2 sections. Like "basic" and "advanced". As a beginner, I wouldn't thought of what was written here. Like "basic" section will contain simple menu. And "advanced" that will reveal all capabilities of "menu api" in tauri.

[vasfvitor]

I feel like the example is a bit extreme. I think it should be more basic for the docs.

What do you think of placing it in the labs/learn section? Someone can make a streamlined version to be in the guide/develop

[StepanZagray]

I have a question, where do you guys usually edit docs files? Like in codespace? Or do you have locally this repo, and edit it with your IDE?

[FabianLars]

A local clone and then vscode and the terminal

[StepanZagray]

I agree with @FabianLars , the example on the plugin example should be a basic one and also I like the approach you're suggesting @vasfvitor and add a lab with the more advanced example.

Honestly, I can't think of a more simple example. You need to create your menu_plugin. Then create tray.rs where you configure your tray and it's menu. In guide I changed example of menu to basic one, with quit, new window, and toggle window features. Then initialize tray and it's menu in setup(), and make window hide on app close. As I said I do not know how to make this example more compact or simpler

[FabianLars]

1. The menu_plugin.rs seems to be unrelated to the tray.
2. I don't think the menu/tray events actually need to do something fancy. Something closer to pseudo code should be enough to get the point across. No need for quit + toggle + new-window because all 3 show the very same tray event.
3. The create_tray is way too large (yes i know it's our repo example), especially since many menu items are the same.
4. I'm not sure whether we should show the hide window thing or opt for the ExitRequested event instead 🤔 -> Either way this should be marked as optional with an explanation that it's only required if the dev wants to keep the app & tray running without open windows -> This may even be moved to a different guide in the future since some may want to keep the app running without a tray icon.

So tldr: for me it's really mostly about all those duplicates.

P.S. I wonder if we should pull out the menu stuff into a menu guide in the future and just reference that there but maybe that's a bit much.

P.P.S. No worries if i'm asking for too much, i know that many Tauri users aren't that experienced with Rust (yet). I'm sure we can take over if you'd prefer :)

[StepanZagray]

Okay, I understood. I will try to simplify guide tomorrow

[StepanZagray]

1. Wow, menu_plugin was indeed unrelated, I was just afraid of deleting it.
2. I don't think pseudo code is a good idea for docs. If I'm using docs I would like to see code that I can just copy and use right away.
3. I made create_tray more compact, leaving only quit, and opening menu on left click functionality.
4. I also think that hide_window is somewhat unrelated to menu_tray. So I removed it from this guide.

[StepanZagray]

So what is the problem, and what I need to fix?

[FabianLars]

I don't think pseudo code is a good idea for docs. If I'm using docs I would like to see code that I can just copy and use right away.

What i meant was "real" code but not much functionality behind it. Like showing how to listen to events, but then just logging it to the console (or just a // React to event here comment). Your changes are close enough to that.

Content wise i think this is good now, thanks!

So what is the problem, and what I need to fix?

Ignore the Status Updater workflow, it is failing for everyone due to missing token permissions.