# Winit meeting 2025-06-05

Date: 2025-06-05T07:00:00Z (UTC)

Attended: @madsmtm, @daxpedda, @kchibisov

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

## Next meeting time?

2025-08-28T07:00:00Z (UTC)

## Since last time

- New DPI release.
- `winit-*` crates split done.
- Still not done: Published call for maintainers.
- @daxpedda is working on other things currently.

## X11 talk

X11 is dying a slooow death. Might make sense some day to look into deprecating it?

Maybe one day: `x11` not in default features.

## Versioning of winit-* crates

Do we need the added flexibility of multiple versions?

Follow one version?

Current situation: The friction is quite high for users when upgrading.

Conclusion: Start from the current Winit version for now.

## `winit-compat`

Provides closure `run` API.

Maybe?

Create window was the actual issue, and we can't provide a wrapper for that (since we can't correctly create the window before the event loop is running).

The problem there is initialization of state.

https://github.com/rust-windowing/winit/pull/3895 is maybe part of the solution?

Maybe the solution is: Provide a helper method for single-window creation.

Idea: Optimize for the common use-case of a single window.

event_loop.single_window_run(
    WindowAttributes::new(),
    |event_loop, window| {
        // Initialized
        App { window }
    },
);

Idea: Provide an API to switch `Box<dyn ApplicationHandler>` to something else?

## Examples

@daxpedda: Our examples are kinda bad, the point of an example is to teach how to use an API.

## v0.31

When?

Soon, clean up the API and figure out casting etc., but wait with further stuff.

Surface/Window split should wait.

https://github.com/rust-windowing/winit/milestone/33

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

### Pen/Stylus

@wareya maybe wants to implement it, we should tell them yes to that.