Issues like #1878, #1928, and #1759 have made it clear that there is a need to hook into platform-specific events that winit itself doesn't (and arguably shouldn't) handle. Ideally, we'd give users the ability to hook into these events with minimal effort, and in a way that doesn't interfere with winit (although some would perhaps like to do that as well).

The simplest solution I can think of to this is to add an EventLoopBuilder struct where you can register platform-specific callback functions before the event loop is ever entered. This will make it so that these callbacks don't miss any events, like the file opening events in #1759.

Granted, this doesn't lend itself to being a particularly ergonomic API, as any data shared between the platform-specific callbacks and the platform-independent on would have to be behind something like an Rc<RefCell<T>> or an Arc<Mutex<T>>. I think there may exist a solution where sharing such state is easier, but I don't want to spend much energy on that ATM.

Another issue is that this will (by necessity) make some projects (like AccessKit) end up depending directly on winit or have to provide an adapter crate. Maybe it could be possible to pull a raw-window-handle and create some cross-windowing-library interface for this, but I don't think it's ultimately going to be all that feasible.

The Windows backend for this should be fairly trivial, so I'll go and implement that soon-ish, unless there are any major concerns with this proposal.

This is on some level related to #2010, but this concerns the public API, rather than the internal one.