Update winit to 0.30

[moshen]

• Update winit example to use run_app
• Update winit example to proxy MenuEvent

I wasn't sure about a couple of things re cross platform because I don't have linux or mac setup to test on.

I also omitted event_loop.set_control_flow(ControlFlow::Wait); as it appears ControlFlow::Wait is the default.

[poyhen]

hi, any idea why the events are not caught? the menu doesn't appear in your updated example.

it works when event_loop.set_control_flow(ControlFlow::Poll); but that burns lots of cpu cycles.

in my app i also have other events which work fine (listening a websocket and firing a notification) with event_loop.set_control_flow(ControlFlow::Wait) however i couldn't make the menu appear too (somehow all events and menu pop up appear after the notification triggers the event loop but clicking the tray icon itself doesn't)

(windows 11 24H2)

[moshen]

Weird, running on Windows 10 22H2 and it appears to work correctly for me.

When I run with:

cargo run --package tray-icon --example winit

I can view and click the menu:

TrayIconEvent(Click { id: TrayIconId("1"), position: PhysicalPosition { x: 2304.0, y: 1420.0 }, rect: Rect { size: PhysicalSize { width: 24, height: 40 }, position: PhysicalPosition { x: 2297.0, y: 1400.0 } }, button: Right, button_state: Down })
MenuEvent(MenuEvent { id: MenuId("1001") })

The click on the tray icon is a TrayIconEvent, with the click on the menu itself being a MenuEvent.

I'm not sure what to tell you about Wait vs Poll. I'm using Wait with multiple winit windows and egui events being proxied, and I haven't run into them not firing, but all the examples I've seen of winit / egui change the control flow to Poll 🤷‍♂️.

[moshen]

@poyhen I did notice when looking at the eframe example the events seem delayed.

[poyhen]

winit 0.29 seems to work fine, it happens on 0.30 series so not entirely sure whats going on considering it works fine on your windows 10 22h2. haven't tested egui yet i can try that one tomorrow

[poyhen]

@moshen yup similar issue there with egui. tried with a few version and they seem to bump to winit 0.30 in their 0.29 release (https://github.com/emilk/egui/blob/master/crates/egui-winit/CHANGELOG.md#0290---2024-09-26---winit-030) and can reproduce same issue with it. it seems the change in winit 0.30 to use .run_app instead of .run has different behavior

[moshen]

@poyhen I was looking at my project and I was using winit 0.30.5, and I saw this release w/ notes for 0.30.6 :
https://github.com/rust-windowing/winit/releases/tag/v0.30.6

On Windows, make ControlFlow::WaitUntil work more precisely using CREATE_WAITABLE_TIMER_HIGH_RESOLUTION.

When I force 0.30.6+ I see the behavior you're referring to. The tray icon context menu no longer works.

[moshen]

@polyhen , This appears to have been fixed in winit 0.30.8:
https://github.com/rust-windowing/winit/releases/tag/v0.30.8

[moshen]

Sorry, forgot to test the linux build 😬

Kind of still a newbie with Rust stuff

[moshen]

I have no idea what I'm looking at here:
https://github.com/tauri-apps/tray-icon/actions/runs/12642322406/job/35227136327?pr=220

[FabianLars]

Just ignore the covector workflow. 🤷

[poyhen]

@polyhen , This appears to have been fixed in winit 0.30.8: rust-windowing/winit@v0.30.8 (release)

can confirm it works now. thanks a lot for the update. your pr helped me a lot!