Add ActiveEventLoopExtWindows::rwh_06_window_handle

[amrbashir]

• Tested on all platforms changed
• Added an entry to the changelog module if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality

This can be helpful when I need to listen to a few native win32 messages by using SetWindowSubclass on the winit event loop window target HWND.

Alternative would be for me to create a hidden win32 and listen on messages on it but for simple use cases this is an overkill IMO.

[notgull]

If the intention is to be able to subclass the window target window, I think it would be better to expose that functionality directly. Maybe just with an "add_subclass" function, in addition to this code:

[kchibisov]

I'm worried that the current code is more of an implementation detail rather than how it'll always be, from what I can see, since there were issues with this design wrt loop blocking during resize, so I'm not sure whether exposing it makes sense, since we could always change that and supporting API for what we don't need internally would be rather strange.

[amrbashir]

If the intention is to be able to subclass the window target window, I think it would be better to expose that functionality directly. Maybe just with an "add_subclass" function, in addition to this code:

any reason to do this? I mean it will basically be the same, get HWND and call SetWindowSubclass. I'd argue that just exposing the HWND is more flexible, as it will allow me to use either windows-sys crate or the full featured windows crate.

[amrbashir]

I'm worried that the current code is more of an implementation detail rather than how it'll always be, from what I can see, since there were issues with this design wrt loop blocking during resize, so I'm not sure whether exposing it makes sense, since we could always change that and supporting API for what we don't need internally would be rather strange.

Do you mean that winit maybe, in the future, decide to not depend on a hidden window for the event loop? if that does happen, It will probably include a breaking change and won't be a problem to remove this method as well.

[kchibisov]

I think getting a window handle out of event loop is rather confusing, since there's no window semantically. So juts an API that gets you HWND could be actually better in that case.

[amrbashir]

Exposing the HWND directly will make it even a lot nore easier to consume. I was just a bit conservative and wanted to stay close to a similar method for display handle.