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)
• 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.
• 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.
• Along the way introduce the winit-common crate to have shared functionality between the crates, which will be intended for winit internal usage and help writing new backends.

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

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