Split Winit up into multiple crates

[madsmtm]

Part of #3367, opening to discuss separately.

Winit is designed around a single crate with a specific set of backends, which is great for users that can use that, but there is a need for other backends that are not implemented in Winit today, like GTK. Additionally, the backend-specific extensions that we do have usually constrain some other part of the design.

So it would probably be useful to try to split Winit into multiple smaller crates (though still in the same repository), to ease doing this work. The top-level winit crate would still remain.

Along with this, we'd want a way to write out-of-tree backends, and allow the user to integrate them into their application. This could probably be solved by introducing internal / "backend" traits, and keep a dyn in structures inside the winit crate.

A rough implementation plan could be:

• Create a winit-core crate, which contains the common types that all backends use (like dpi and keyboard types)
• Make traits in winit-core, that implements the desired functionality, and move each backend to also implement those traits.
• Move the main winit crate to an API that is not cfg-based, but dyn Trait-based.
• Introduce a winit-common crate to have shared functionality between the crates, which will be intended for winit internal usage and help writing new backends.
• Move the backends out into separate crates, which all depend on winit-core, but still have the main winit crate "merge" these backends with cfgs, not with a trait.

@kchibisov: I've tried to fairly faithfully reproduce what I felt was the important points from #3367, but please edit this issue description with your own.

EDIT: Implementation history:

• Refactor to dyn traits:
  • cursor: refactor CustomCursor to be dyn #4163
  • api: make VideoModeHandle into VideoMode #4060
  • monitor: refactor MonitorHandle to store dyn object #3927
  • api: convert Window to dyn Window #3857
  • icon: refactor Icon to be dyn #4182
  • event_loop: group core API in EventLoopProvider #4221
• Refactorings:
  • Remove dummy() from WindowId and DeviceId and use Option<DeviceId> #3864
  • Merge all WindowId into a single type in the core crate #3902
  • api: add DeviceId::{into,from}_raw #3941
  • Add as_inner helper method on trait objects #4160
  • chore: Import from winit-core instead of the top-level crate #4225
  • Move EventLoopExt* to winit-core #4228
  • Use workspace dependencies everywhere #4240
  • chore: Move event loop recreation check into backends themselves #4257
• Core split: winit-core: new crate #4208
• Figure out naming: Backend naming #4246
• Moving backends:
  • Common: Move shared code to new crate winit-common #4241
  • Android: Move Android backend to winit-android #4250
  • AppKit: Move AppKit backend to winit-appkit #4248
  • Orbital: Split Orbital backend out into winit-orbital #4243
  • UIKit: Split UIKit backend out into winit-uikit #4242
  • Web: Move Web backend to winit-web #4249
  • Windows: Move Windows backend to winit-win32 #4247
  • Wayland: Move Wayland backend to winit-wayland #4252
  • X11: Move X11 backend to winit-x11 #4253
• Reserve crate names (DONE).
• Move top-level crate: Move winit itself to crate #4258
• Docs + changelog cleanup: TODO
• Clean up CI: TODO
• doc_auto_cfg: TODO
• Rename / refactor extension traits: TODO
• Figure out how we do releases / versioning: Use a shared version number for all winit-* crates #4274
• Make sure features like serde is properly enabled throughout: TODO

[amrbashir]

Is there any interest in splitting dpi types into its own crates?
There is a few crates that we maintain at Tauri that use Physical/Logical-Size/Position, and they are duplicated in each crate, currently muda and tray-icon crates but now that wry also needs, it is time to create a new crate.

We would also need to incorporate #2395 as we already included that change in our fork which was implemented based on #2148.

[madsmtm]

Is there any interest in splitting dpi types into its own crates?

Hmm, I guess that actually makes a lot of sense - and it might even be useful for glutin and softbuffer to use PhysicalUnit<NonZeroU32> for their widths and heights?

I've reserved the crate name dpi for now.

[amrbashir]

I'd be happy to help with the migration if there is a repo I can contribute to, or should it live within this repo?

[madsmtm]

I'll bring it up in our meeting on friday, then I'll get back to you with a plan.

[madsmtm]

We talked about it, and don't really think we want to pull in the extra dependency for softbuffer and glutin. That said, if there is interest in a separate crate, then we're fine with maintaining it, though we'd probably want it to stay in this repo, as that's much easier to maintain.

I think we agreed on doing the split like I described in #3455 (comment), have put up #3518 to move the module, then you're free to submit PRs to improve that afterwards.

[ten3roberts]

Hey, thank you for this initiative.

Do you think a split like this would enable us to use winit types (like keycodes) independently from winit and in external APIs. I am finding winits input and event types, especially the KeyCode to be massively beneficial to use in e.g game engine or ui library public APIs rather than re-defining the enum and using into/from.

Would this be a usecase you would be willing to support, I.e; using winit even types in the API (I am ok with breaking changes and refactors, just as long as I can use these in an API) :)

[kchibisov]

Given that the winit-core won't depend on anything else I don't see an issue with using it, if you want so.