feat: Event::Reopen support for macOS

[I-Info]

• 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

Description

This event is typically used to handle dock icon clicking event on macOS and uses applicationShouldHandleReopen:hasVisibleWindows: callback from AppKit Framework.

Use case

It will make it possible to keep application running in backgound when all windows are closed, and create new window after dock icon clicked (application reopen callback).

[madsmtm]

I can see this being useful, thanks!

[kchibisov]

nack for 0.30, should be good for 0.31 with traits.

[madsmtm]

nack for 0.30, should be good for 0.31 with traits.

I'm not going to block this on 0.31, it's a simple change that we can do now, and generally enables better behaviour on macOS.

[kchibisov]

And what should we do with all of that on other platforms? The event is macOS specific, but it bleeds into other backend and people will demand its handling, while in reality such event doesn't exist for them.

You should never trade quality for short term wins, this is just straight reduces overall quality because the event is not tied to window in particular and leaves the impression that such thing should be handled.

[madsmtm]

And what should we do with all of that on other platforms? The event is macOS specific, but it bleeds into other backend and people will demand its handling, while in reality such event doesn't exist for them.

I think the event is well documented as "Unsupported", which we already have precedent for, I don't see the issue with adding another one.

In the end it won't really matter, since we're going to be changing things for 0.31 anyways. But like I said, in the months until that happens, this is a useful feature.

[kchibisov]

In the end it won't really matter, since we're going to be changing things for 0.31 anyways. But like I said, in the months until that happens, this is a useful feature.

No it's not, because it'll assume porting it to other backends as a top-level event. If you want this feature, require the new application trait for that and wire the vtable like we've discussed, so it won't bleed into any other backend.

[daxpedda]

I nominated this specifically because I wanted to discuss this "blocking it because its platform-specific" issue in general, but we didn't get to it unfortunately.

Personally I strongly disagree that this somehow reduces the quality of the Winit API, we already have a big amount of events that are not cross-platform, this doesn't change anything.

That said, I'm glad we are trying to fix/improve this issue in v0.31.

[kchibisov]

All Event stuff is cross platform and has special semantics. WindowEvent stuff has specifics, but not the Event.

As I said, the solution is already here even for 0.30, if you want I can write it myself for macOS.

[madsmtm]

Instead of exposing this through Winit, #3758 is going to allow listening to NSApplicationDelegate events outside of Winit using objc2::declare_class!, Objective-C, Swift, or similar.