---
# System prepended metadata

title: Winit meeting 2024-05-03

---

# Winit meeting

Date: 2024-05-03T15:00:00Z (UTC)

Attended: @notgull @daxpedda @kchibisov, @madsmtm (late)

Last meeting notes: <https://hackmd.io/Vh-qKqoWQQWXctxTMJIunQ>

## wgpu + winit 0.30 + web = pain you never asked for

Maybe we should add a special trait for the web with `async` sync
points, which will take a precedence over the `sync` API we provide
in `ApplicationHandler` trait.

Something like `AsyncApplicationHandler`, which could be used with
the loops supporting it (but maybe `WebApplicationHandler`, so you feel
more like a web application developer here...)

The original plan was to use `pollster`, but because of kchibisov's ignorance
about web stuff in general and the fact that `pollster` doesn't work on web,
we have unfortunate situation right now.


Probably we could have a `vtable` extension based trait stuff, which have
sync points with e.g. main `ApplicationHandler`, but does `await` or maybe
web should have its own all `async` stuff, but just be glued into common
`sync` code in the top level, where users could opt into direct `async`
stuff.

https://github.com/rust-windowing/winit/issues/3626
https://github.com/rust-windowing/winit/issues/3560


```rust!
trait ApplicationHandler {
    async fn resume(...);
    async fn new_events(...);
}

struct App;

impl ApplicationHandler {
    async fn resume() {
        // Async code only on Web?
    }
}



trait WebApplication : ApplicationHandler {
 async fn resume()
}

fn spawn<D: ApplicationHandler>(data: &D) {}

fn use_async<D: WebApplication>(data: &D) {
    state.async_ptr = data.resume;
}
```

Idea: Winit becoming an async executor?

## Close github discussions

Given that we redirect to matrix in issue tracker maybe it'll make
more sense to do so.

We had such conversation before, but maybe it's time now?

## Nominated

https://github.com/rust-windowing/winit/labels/C%20-%20nominated
