# Winit meeting

Date: 2025-03-07T15:00:00Z (UTC)

Attended: @madsmtm, @kchibisov, @daxpedda, @MarijnS95

Last meeting notes: <https://hackmd.io/Xr1LFKF0RfO7h_2lDEdL5A>

## Organizational changes since last time

We previously decided:

> #### Merging public API PRs without full approval from everyone
> Two approvals for public API, then it's fine to merge, as long as we have enough people that review.

But @kchibisov [lowered the merge requirements](https://matrix.to/#/!DGpLzJTRzBDTwZiogk:matrix.org/$H0bN1_dtLst4GJk38Z2sEHELo3IbUqZATEZvPg7VTHs?via=matrix.org&via=mozilla.org&via=catgirl.cloud), because we are low on maintainers.

@madsmtm [proposed](https://github.com/pyfisch/keyboard-types/issues/60) for `keyboard-types` to be put under @rust-windowing.

## We are low on maintainers!

Not the first time:
- https://github.com/rust-windowing/winit/issues/830

Ideas for fixing it:
- Make it easier for people to contribute?
- A test suite would help.
- `cargo-nextest` would help with macOS/iOS (process isolation). `--test-threads=1` could do most of the same.
- @daxpedda has been working on test support in `wasm-bindgen`
- Can we be more welcoming?
- Give people ownership and agency.
- Wgpu triages PRs every week, and assigns people to review them.
- We clearly don't have the bandwidth to do so, but maybe that's something we could strive for?
- Call for help?
- Maybe with a wider audience to [TWiR](https://this-week-in-rust.org/) + Reddit + Discourse forums?
- [Also done before](https://gist.github.com/Osspial/1a93d599189f49a97884c4aa033e9ef3).
- @madsmtm will write something.
- We need Windows maintainer
- Android needs help in `android-activity`
- Just needs you to care and be able to bounce off ideas
- Web needs help in `wasm-bindgen`?
- Ask downstream projects if someone on their team wants to be platform maintainers?
- Bevy, Linebender (Xilem), Egui?
- Tauri and Wgpu?

## Status on API -> traits rework?

[MonitorHandle](https://github.com/rust-windowing/winit/pull/3927) PR.

What do we need to do to move forwards? Who will do it? Who will review?

@kchibisov will maybe do cursor -> `dyn` and `EventLoop` -> `dyn`, @madsmtm will have the time to review.

## Responding to [#3626](https://github.com/rust-windowing/winit/issues/3626)

- Original motivation for trait-based event handlers
- Synchronous handling of events
- Feedback from user
- Will enable easier breaking changes?
- Other?
- Winit next: https://github.com/rust-windowing/winit-next/blob/05b8fd0792c3794dbf073746c3cba8c10eb6ea84/winit-wayland/examples/window.rs#L54-L110
- Most users do _not_ want to do this!
- As evident by the whole `Event<'_>` debacle
- Which APIs do we actually need to be sync?
- Window creation
- Window close requests
- Surface resizes
- Redraws
- Keyboard input
- ?
- Are there other options for doing this?
- Maybe simply documenting that certain events _should_ be handled synchronously (like resizes), and that you'll get glitches otherwise?
- Maybe add extra APIs on `event_loop` that "resolve" the request. Like:

        fn window_event(&mut self, event_loop: &dyn ActiveEventLoop, event: WindowEvent) {
            match event {
                WindowEvent::CloseRequested => {
                    event_loop.accept_close().unwrap();
                }
                WindowEvent::CloseRequested(inner) => {
                    inner.accept_close(event_loop);
                }
                _ => {}
            }
        }

Somewhat roundabout, but allows `WindowEvent` to still be pure data.

## Other [nominated](https://github.com/rust-windowing/winit/labels/C%20-%20nominated) issues and PRs

## Loose VSync discussion

Should be possible everywhere, except for X11, the [this](https://fishsoup.net/misc/wm-spec-synchronization.html) is only available on Gnome :/

We could fake it though.

[Old attempt](https://github.com/rust-windowing/winit/pull/2535).

Presentation info:
- Vulkan doesn't have an API for presentation stuff.

Current API:
- `request_redraw` should be callable everywhere, and then you get `RedrawRequested` at a reasonable point in time.

## Next meeting

2025-03-28T05:00:00Z (UTC)