Platform specific traits and requests extensions

[kchibisov]

We generally could allow users to use the downcast API and IDETs to use extra winit functionality without adding cfg guards, they'll just have to cast before calling something, but if the cast will be always be None it'll be optimized out, so effectively the same as using cfg just your code is always compiling and it's easier to write cross platform code without testing
all the features.

[kchibisov]

Hm, after discussion in winit repo and #winit on matrix we come to conclusion that the only way it can work when the main type has all IDETs, so IDETs can't live in their own crate or at least it doesn't make any sense for them to be there.

However, for extensibility purposes the approach to use vtable like structures and populate them by downcasting event loop to the actual event loop type of the backend is what could be done for out-of-tree backend events.

The actual mechanism for such a thing could look like:

impl FancyBackendVTable {
  fn set_foo_callback<T, F: Fn(&mut T) + 'static>(f:F) {
    self.foo = |app| f(app.downcast_mut::<T>().unwrap());
  }
}

[kchibisov]

Unfortunately, the dyn approach is really tricky to get and rust can't really figure out the type when dyn itself is passed around. However given that EventLoop is generic over State, we can just require everything to be generic over it.

An example of such extensibility is show cased in rust-windowing/winit-next@05b8fd0 .

cc @madsmtm @daxpedda

The point why such thing is even needed, is to erase the MyCoolTrait and not have it in winit-core.

[madsmtm]

I got it, makes sense. But yeah, does require the A: Application bound to be on EventLoop, which is probably fine.

[kchibisov]

That's already the case for the run, since we accept the T: Application.

The thing is that user state is only 1 or 1 doing a composition of other states, however the Window could be anything and also with multiple variants could be present at the same time, thus we can't use generics there.

[kchibisov]

I figured how to do without generic, but with runtime check instead.

rust-windowing/winit-next#4

So yeah, we can pick whatever we like more. Probably without generic is a bit more flexible.