Tray Icons

[n1ght-hunter]

continue of tray discussion from #3433
for anyone else here is the code being referenced
https://github.com/n1ght-hunter/winit/blob/v0.29.x/src/platform_impl/windows/tray.rs

[n1ght-hunter]

@daxpedda to answer your question yes i need the internals of events loop.
there is also things like this that are nice to reuse.

        hInstance: util::get_instance_handle(),
         util::encode_wide("my_window");
         DESTROY_MSG_ID

[daxpedda]

I think when we split up the crates we will have a chance of discussing if we want to expose certain stuff in a separate utility crate.
Though I really doubt it, because the things you are asking for are all a couple of lines. util::encode_wide is just a redirection to Stds OsStrExt::encode_wide().

In any case, I think this deserves its own discussion in much more detail when we actually reach the point of splitting crates.

[n1ght-hunter]

i agree and am happy to try work out something with winit. but i figured i should bring it up befor the winit split to try work out the best way to handle this for the ecosystem

[n1ght-hunter]

i haven't looked at it too closely but i imagine there would be things to reuse for macos and linux.
for reference what i want is to create is a nice way integrated with winit to create tray icons.
this does NOT include the window that may open when you click on the icon.
End goal is to allow creation of non native tray icons primarily for iced but also any gui to build on top of. you could actually build a native one ontop of this but thats a separate matter

[n1ght-hunter]

basically the native is using the native os api to build and render the window that is opened when your click on the icon. but you dont actually need to do that u can just render whatever type of window u like

[daxpedda]

"whatever type of window" what do you mean by that?
Are there non-native window types?

[n1ght-hunter]

this an example of a native tray icon window for windows.
basically if you use only the windows api to build it this what you get

here is an example of a nonative tray icon window
so you use the windows api to create the trayicon. but on click instead of opening and rendering a native tray icon window. you have a genric window and can render anything you want. i.e. use softbuffer/wgpu to draw on the surface and render anything.

[daxpedda]

Ah, you mean the rendered content!
AFAIK both windows use the same API (apart from its type, e.g. popup window), its just whats inside that's different.

Winit should definitely be able to support the latter by providing the window, we still have to see if the try icon will be supported by Winit itself or if we will make an external crate be able to it.

I don't know if and how window native UI elements can be used with Winit, but I guess Winit should also be able to allow that.

[n1ght-hunter]

ya thats what i want to work out with winit. i dont mind integrated into winit or a separate crate. just want to sort something out that should work for most people and is easy to use with winit.

i cant find the gif but i actually have a working version of with winit and wgpu for rendering the popup window

[n1ght-hunter]

gif of what i have

inside the black ring is the part i want to integrate with winit.
the white window is just a normal window that you can spawn when you click on the icon

[daxpedda]

Did you actually take a look at tray-icon yet? I think it would do what you want here.

I do however think that this whole use-case justifies either integration in Winit or #2120. Because while it is possible to do this without Winit, it requires creating a non-existent window and a separate event loop. This is similar justification to clipboard integration.

Related: #403.

[n1ght-hunter]

yup i know and have used the tray icon crate quite a bit. it is nice but the way to integrate with winit feels janky. also its uses gtk on linux to build the window which i and i think quite a few others would rather not have as a dependency