On macOS, fix WindowEvent::Destroyed isn't emitted

[wusyong]

It seems windowWillClose can only be called when windowShouldClose returns true.
So the WindowEvent::Destroyed is never called when the window is dropped.
This PR add another queue event when the window is dropped during Drop trait is called.

• Tested on all platforms changed
• Added an entry to CHANGELOG.md 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
• Updated feature matrix, if new features were added or implemented

[madsmtm]

Huh, odd that this hasn't been discovered before! Does this mean that our overriding of windowWillClose: is effectively useless?

However, I doubt this fixes the problem completely, since the window may be closed before the last reference to it is destroyed (for example in the window_debug example). Do you have an idea for how to fix this?

[madsmtm]

Nit: Use window.emit_event

[wusyong]

Only WinitWindowDelegate has this method. Should I add such method to WinitWindow too? Or could I just access WinitWindowDelegate by pub(crate) it.

[madsmtm]

Just do pub(crate)

[wusyong]

I found the delegate has to be used in exec_async somehow, so windowWillCose can be invoked.
So I call delegate.window.close() instead which should look a little bit cleaner.

[wusyong]

Does this mean that our overriding of windowWillClose: is effectively useless?

I couldn't find any other way to trigger windowWillClose: than returning true in windowShouldClose:.

However, I doubt this fixes the problem completely, since the window may be closed before the last reference to it is destroyed (for example in the window_debug example). Do you have an idea for how to fix this?

Yeah, Destroyed event won't be sent in this case but it's consistent across platforms (at least on x11 and windows). But I assume that's okay if you are already going to exit. In my use case, I treat Destroyed event as a way to gracefully shutdown. I have a collection of window (HasMap for example). CloseRequested will drop the window in the collection and set_exit if the collection is empty during Destroyed.

[madsmtm]

I couldn't find any other way to trigger windowWillClose: than returning true in windowShouldClose:.

Then we should maybe remove the code in it, along with a note? Though I'm a bit weary about doing so, since it seems like, see this commit from 2018 that added the note about El Capitan goddessfreya@8e9fc01 (from PR #853).

@francesca64 do you remember anything about this?

Yeah, Destroyed event won't be sent in this case but it's consistent across platforms (at least on x11 and windows).

Would you mind documenting this on Event::Destroyed, then?

[francesca64]

@madsmtm I sadly don't remember, sorry!

[madsmtm]

No worries, thanks for the quick response!

[madsmtm]

I've discovered that windowWillClose: is called if you run close: synchronously, which means this should be fixed by #2574, could I get you to verify that @wusyong?

[wusyong]

@madsmtm I slightly modified multiwindow example and check windows hash map on Destroyed event.
It can work based on your PR! I can close this one if you are going to merge #2574.

[madsmtm]

Cool, I went and merged that so will close this now.

Thanks for your help!