Currently, the Closed event indicates when a window has been destroyed, and clicking the × button (or closing the window through some other external means) leads to the unconditional destruction of the window. Ideally, application developers should have the opportunity to decide how to handle external requests for the window to close, such as prompting the user about unsaved work, but that's not presently possible.
Proposal
A new event named Destroyed should be created, taking the place of the existing Closed event. This is consistent with the naming scheme used in both Win32 and X11.
The existing Closed event should be removed in favor of CloseRequested. This prevents existing code from missing the API change, and prevents ambiguity in future code. When × is pressed/etc., the only behavior that should occur is this event being sent, allowing the application developer to decide what action to take.
A close method could be added to Window (#13). In the simplest case, CloseRequested would be handled by calling close for that window. However, since this method would have the same effect as dropping the window, it could be preferable to leave out this method and just make dropping the canonical solution.
Currently, the
Closedevent indicates when a window has been destroyed, and clicking the × button (or closing the window through some other external means) leads to the unconditional destruction of the window. Ideally, application developers should have the opportunity to decide how to handle external requests for the window to close, such as prompting the user about unsaved work, but that's not presently possible.Proposal
A new event named
Destroyedshould be created, taking the place of the existingClosedevent. This is consistent with the naming scheme used in both Win32 and X11.The existing
Closedevent should be removed in favor ofCloseRequested. This prevents existing code from missing the API change, and prevents ambiguity in future code. When × is pressed/etc., the only behavior that should occur is this event being sent, allowing the application developer to decide what action to take.A
closemethod could be added toWindow(#13). In the simplest case,CloseRequestedwould be handled by callingclosefor that window. However, since this method would have the same effect as dropping the window, it could be preferable to leave out this method and just make dropping the canonical solution.