Have you thought about how you would approach removing winit dependency from ribir_core?

[zoechi]

Referring to #233
winit has quite a broad API surface. Creating an abstraction would result in a lot winit's public code to be copied to ribir_core and then somehow mapped between ribir_core and winit at runtime.
I also wonder, how easy or difficult it would be to map to a alternative implementations when the abstraction is based on winit.

An alternative I can think of is to annotate access to winit API with feature cfg, but then access to every alternative implementation would need to be prepared in ribir_core.
The dependency to winit would not be removed entirely, but at least it could be made optional.

I haven't looked at ribir_gpu yet.

Any thoughts?

[M-Adoo]

I haven't given it much thought, but I don't expect it to be through feature cfg, nor by wrapping the API of `winit'.

My preference is to let Window as a trait keep the basic APIs that all windows should provide, such as resize, title, icon, etc. If some specific API is desired, the user should convert to winit::Window or some other window type they are using via downcast_ref.

The Window, Application and event loop should be removed from ribir_core. The `ribir_core' is only used for the content in a window and can be used as a library which is not dependent on any platform. Or even run it on the server end to output the paint commands and then render them on the client end.

[zoechi]

Sounds good. I'll have another look.
I can't guarantee anything of value will come of it, but I want to take a stab.