# Winit meeting

Date: 2024-08-23T15:00:00Z (UTC)

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

Last meeting notes: <https://hackmd.io/_YK76P6-TQq2Rw3s3Y3y_g>

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

### https://github.com/rust-windowing/winit/pull/3479

Either get it in, or rewrite that part of the docs.

### https://github.com/rust-windowing/winit/pull/3751

John: The more the merrier, people have issues on certain niche targets.
Idea: Tier system
- Tier 1: It works
- Tier 2: It compiles

Problem: The CI gets longer and longer for "little gain".
Would it make sense to only run on release?
Rustix: Has to test all of the targets, since there's a lot of subtleties.

Conclusion: John will open a new PR, with a deeper discussion of which targets we actually "support"
Done: https://github.com/rust-windowing/winit/pull/3887

### https://github.com/rust-windowing/winit/pull/3776

Monitors could become invalidated if you wait too long before you poll the event loop.
And we don't want to provide users with things without a lifetime outside of the event loop.

### https://github.com/rust-windowing/winit/pull/3786 / https://github.com/rust-windowing/winit/issues/3779

### https://github.com/rust-windowing/winit/pull/3795

Moving to explicit methods instead of `From`.

## Converting everything to `dyn`

https://github.com/rust-windowing/winit/issues/3433
Case: https://github.com/rust-windowing/winit/pull/3857

Might be a bit late for me to start this discussion, but I _feel_ like this refactor might not be sufficiently motivated?

It definitely complicates the user-facing API!

Just to understand, what are the _actual_ problems that we're trying to solve?
- Allow backends outside `winit` repo.
- GTK
- QT?
- DRM/KMS
- Redox/Orbital
- N Wayland backends
- Allow backends to define platform-specific behaviour and callbacks/handlers without polluting the global handler.

Is that all? Or is there something here I'm missing?

If that is the problems we're trying to solve, then I believe there are better solutions (not necessarily better in terms of the implementation, but definitely in terms of the user).

Please don't take this wrongly, I'm just concerned that we might be complicating something we don't need to!

**Primary motivation**: Social. Maintainers come and go.

### Window trait

There are different kinds of window that share common logic.
- Subsurfaces, ...

Doesn't really need `dyn`?

### Different protocols

Wayland protocol extensions, Wayland users could define custom ways to build the window.

X11 could also use ...

### Maybe don't expose `dyn` to the user, but instead wrap

struct Window(Box<dyn winit_core::Window>);

trait winit_core::Window {
    fn set_title(&self, title: &str) {
        ...
    }
}

impl Deref for Window {
    type Target = dyn winit_core::Window;
    fn deref(&self) ->  {
        // ...
    }
}

### Idea for external backends

Backends outside repo alternative hacky:
Declare the backend in `Cargo.toml`:

[features]
unstable-gtk = ["gtk-backend-tauri"]

[dependencies]
# Intentionally `~version`, since we e.g. add a method in Winit core,
# and that would break this, and then we'd need the ...
gtk-backend-tauri = { version = "~1.2.3", optional = true }

In `platform_impl`, do something like:

#[cfg(feature = "unstable-gtk")]
use gtk_backend_tauri::*;

#[cfg(not(feature = "unstable-gtk"))]
// ...

This would only require us to:
- Expose the core types (which we have to do anyways with the other approach)
- Keep a list of alternative backends around
- Update the backend once the inner crate is updated to support newer Winit APIs

We don't even have to provide CI that runs this, we could just say that's up to the external implementation

### `WindowEnum`

We can consider providing something like this:

enum WindowEnum {
    AppKit(winit_app_kit::Window),
    UIKit(winit_ui_kit::Window),
    X11(winit_x11::Window),
    // ...
}

impl winit_core::Window for WindowEnum {
    // ...
}

## PointerCancel vs. PointerLeft

https://github.com/rust-windowing/winit/issues/3833 / https://github.com/rust-windowing/winit/pull/3876

Touch doesn't have a concept of leave.

Provided that users track pointer button clicks, they can determine whether it was a cancel or a leave.

The question is: Is there a use-case where we expose PointerCancel?

Conclusion: Merge `CursorLeft` and `TouchCancel` into `PointerLeft`, but should be documented that we have chosen to do this, and that the user can open an issue if there is a use-case for them being separate.

## https://github.com/rust-windowing/winit/pull/3864

Good to move forwards with.

## 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.

## `MonitorHandle`

It works something like this internally:

struct MonitorHandle {
    internal_id: *const InnerHandle,
    cached_refresh_rate: Arc<Mutex<u32>>,
    // ...
}

impl MonitorHandle {
    fn refresh_rate(&self) -> u32 {
        *self.cached_refresh_rate.lock()
    }
}

impl EventLoop {
    // Internal
    fn monitor_handle_update(&self) {
        *self.monitors.get(id).cached_refresh_rate.lock() = new_refresh_rate;
    }
}

Should use `Rc<Cell<u32>>` instead, so it's only main-thread safe.