Rework event handling to be based on a trait

[madsmtm]

Part of #3367, opening to discuss separately.

Winit needs some way for the user to synchronously respond to events with a value.

Prominent examples include:

• the dead key API (it goes via globals now).
• Deal with scale factor changes/configure races on Wayland #2921
• Allow some events to perform cancellation. #3349
• Support Back button/KeyCode on Android #2304 (requires saying that you've handled, otherwise you'll block everything)
• Guarantee sending WindowEvent::Resized on window creation? #3192 (you need to ask during window creation)
• Clipboard APIs (we need to pick mime-type), the same with DND.
• Live resizes (when you can adjust the size during resize).

To do this, we propose allowing the user to implement a trait, where each method is a callback that will be called when a certain event happens. Roughly:

// API
pub trait ApplicationHandler {
    fn new_events(&mut self, event_loop: ActiveEventLoop<'_>, start_cause: StartCause);

    fn resized(
        &mut self,
        event_loop: ActiveEventLoop<'_>,
        window_id: WindowId,
        size: PhysicalSize<u32>
    ) -> bool;

    // ... Further events
}

// User code
struct App {
    window: Option<Window>,
}
impl Application for App { ... }

fn main() {
    event_loop.run(App { window: None })?;
}

Feel free to update this code-block once we narrow down the actual API.

---

Identified problems to which we need some sort of solution:

• It is hard to implement middleware / "mini-batching". Prominent example: egui-winits on_window_event.
• How do we allow dbg!(event) and similar logging that access all events.
• How do we allow platform-specific / backend-specific events? Related: Platform-Specific Enum Variants #3064 and Platform specific traits and requests extensions #3474.
• TODO: Further problems???

Implementation plan:

• Create new user-facing handler trait ApplicationHandler, while still keeping the Event-based API around to ease transition. Initial work in Begin transition to a trait-based system #3386.
• Change backends such that they do not (unnecessarily) queue events.
  • macOS
  • iOS
  • Windows
  • Web
  • Wayland
• Move each backend to these traits internally. Example in Example of migrating backends to ApplicationHandler #3387.
• Implement APIs that require feedback from the user, like clipboard.

[madsmtm]

Re mini-batching problem:

@daxpedda suggested a design similar to tracing-subscriber, something like an extra crate winit-subscriber, linking his in here, but he ultimately realized it isn't going to work, so we need some other way to solve it.

We discussed a potential solution at our last meeting, I'll try to write a bit more about that in the coming days.

[kchibisov]

I'd like to add that for 0.30.0 we agreed that we do what the current design is doing and that tracing subscriber approach is more for 0.31.0 version. The resolution for 0.30.0 was to have a method that can will be called before each event.

[madsmtm]

We discussed the mini-batching problem and the platform event trait problem today, meeting notes here.

One of us still needs to write up some more details on this, but we think it should be possible.

[nicoburns]

Regarding platform-specific events, why not define the methods on all platforms but just not call them on irrelevant platform(s)? (or alternatively have them as conditionally compiled trait methods). So long as the methods had a default implementation then it would be quite usable I think.

[kchibisov]

The said issue is solved for 0.31, adding subpar solution for that into 0.30 is not appealing to me. In general IDETs/vtable + as_any solves that really good, but you need to go hard on traits, as long as you still have enum Event it won't really work.