Add WakeUp event to App

[IceSentry]

Objective

• The WakeUp event is never added to the app. If you need to use that event you currently need to add it yourself.

Solution

• Add the WakeUp event to the App in the WinitPlugin

Testing

• I tested the window_setting example and it compiled and worked

[ickshonpe]

This doesn't look right to me. From what I can tell the problem isn't that the WakeUp event registration is missing. It's that WakeUp derives Event but it's not actually used as a Bevy event. Instead it's dispatched directly to winit using EventLoopProxy::send_event.

I think instead either the Event derive needs to be removed for WakeUp or there should be a system that redispatches the events like:

fn redispatch_winit_event<E = Event>(
    mut events: EventReader<E>,
    event_loop_proxy: Res<EventLoopProxyWrapper<E>>,
) {
    for event in events.read() {
        let _ = event_loop_proxy.send_event(event.clone());
    }
}

And then in the WinitPlugin<T> builder it would add a redispatch_winit_event<T> system to the schedule.

[IceSentry]

So, the reason I made this PR is that we have code at work that uses that WakeUp event and while migrating to bevy 0.15 I noticed I was getting a bunch of error about needing to add the Event to the App. Adding the event like this PR does fixed the issue. Looking at the code more, I agree that it doesn't really make sense since neither bevy nor my work code uses it as a bevy event. So I'm a bit confused why that fixed the issue and why I even received the error in the first place since I can't find anywhere that tries to send the event as a bevy event.

Looking at this more, it probably makes more sense to just remove the Event constraint on WakeUp since that doesn't seem to be the intended usage of it.

[IceSentry]

Okay, looking at the code more. I think I found where the send_event happens. It's inside ApplicationHandler::user_event(). It sends any user event emitted by winit back to bevy. The reason this is triggered by our work code is because we send a user event directly to the event loop proxy.

I don't know why that feature exists but I think doing that redispatch_winit_event will result in a feedback loop where it will send that user event then the ApplicationHandler will send the bevy event back in this will constantly happen in an inifinte loop.

So, with that taken into consideration, if we don't want to change/break any existing behaviour, we can't remove the derive and we can't add the redispatch system.

[IceSentry]

I did more digging and I think I figured out what happened. The #15649 PR added a feature flag on this line https://github.com/bevyengine/bevy/pull/15649/files#diff-b7a9bee1adef16186c0b38f7f0d7969565519dba556c0ecd007632ac35725cf5L91 the feature flag was only about the cursor part but it was also added to the add_event which I believe should not be behind a feature flag. That would explain why our usage of this broke in 0.15 but was fine in 0.14.

So the fix seems to be to only add the feature flag on the appropriate part of that line instead of that entire line. I'll push this fix on this branch and see what people think.

[ickshonpe]

Okay, looking at the code more. I think I found where the send_event happens. It's inside ApplicationHandler::user_event(). It sends any user event emitted by winit back to bevy. The reason this is triggered by our work code is because we send a user event directly to the event loop proxy.

I don't know why that feature exists but I think doing that redispatch_winit_event will result in a feedback loop where it will send that user event then the ApplicationHandler will send the bevy event back in this will constantly happen in an inifinte loop.

So, with that taken into consideration, if we don't want to change/break any existing behaviour, we can't remove the derive and we can't add the redispatch system.

Oh right that makes sense now.

My suspicion is that the ApplicationHandler trait is just implemented incorrectly? There doesn't seem to be any need to bounce events back from the user_event method.

[ickshonpe]

Looks good.

It seems to me that there's no need for the WakeUp event, the type params on WinitAppRunnerState and WinitPlugin, or the user_event impl at all but cleaning any of that up isn't urgent.