There are two main ways I can see to handle the modal loops:

• Re-implement the modal loop code, in a non-blocking way, within winit.
• Adjust the event loop API to give winit total control over the application's main loop, even while polling events, so that the user's provided callback can be called within the window procedure.

I'm in favor of the second option, as the first one would involve a lot of work on our end both to create the initial implementation, with proper window snapping support and such, as well as support additional features Microsoft may add in the future.

Any update on this? I'm currently waiting on this because of #506.

If winit ever gets menus / integration with the OS I need to be on the same thread as the HWND, otherwise, Windows just locks up the application.

I'm happy with any solution, but please just make sure that the .get_hwnd() call (which I need to implement Win32-specific functions that act on / modify the HWND) runs on the same thread as the user code.

@fschutt this is blocked on #459, where the current status is "waiting for people to respond to me" #459 (comment) (It's also ostensibly blocked by HiDPI support, which is awaiting responses too #105 (comment). The rationale for getting this in first is because #459 is very much a breaking change and IMO #105 is too important to gate behind that API migration.)

Most people would assume that the best way to help winit grow is by working on the code, but I'd say the best thing someone can do is push API discussions forward. I encourage you to participate in both of those discussions, since doing so will likely lead to a faster resolution.

Closing; obsoleted by #638.