expose winit

[richard-uk1]

I don't think there is a reason not to, and you need winit for some types so currently you must define the crate yourself, which risks version errors etc.

[DJMcNab]

So, this is trying to solve one half of #584?

There are a couple of things to think about here:

1. This is also an intermediate state, see this comment.
2. There are reasonable use cases for using Xilem without winit

I think I'm happiest just leaving it in the state that you need to depend on winit for the moment, especially as you already need to depend on Masonry.

[PoignardAzur]

LGTM.

[PoignardAzur]

I think I'm happiest just leaving it in the state that you need to depend on winit for the moment, especially as you already need to depend on Masonry.

Sorry, I misread this sentence and thought you were approving.

My own perspective is that we'll eventually decouple Masonry from winit (having vocabulary crates for winit events would be a good first step) but until that happens, re-exporting it is fine, and is in line with how we treat other dependencies.

[richard-uk1]

Yes if you decouple then you'd want to reverse this out.