On Fri, Mar 23, 2012 at 18:50, Germán Arias
<german@xelalug.org> wrote:
> All I have to say is:
>
> -(BOOL)
> applicationShouldTerminateAfterLastWindowClosed:(NSApplication*)theApplication
> {
> return YES;
> }
>
> This is a great thing to do in single-window (non-document) apps.
> SystemPreferences seems to qualify. Regular windows should always be
> closable.
>
for handle this apps.
I'm not sure why this is necessary. NSWindow already has a flag which explicitly must be set to make the window closable. Why would this be theme's choice?
The already-implemented NSApplicationDelegate method, -(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication*)theApplication;, is the right approach to understand whether closing the application's window means that app needs to terminate as well.
What if the app is actually multiwindow, but not NSDocument-based? What if it opens windows dynamically? How will you decide whether the close button should be available, in case a theme for some weird reason says "no, please, don't add a close button"? By applicationShouldTerminateAfterLastWindowClosed returning "yes" and the window being the last one? Isn't that a hacky?
Especially in the context of a NeXT-style dock, terminating the app when the last window closes is anything but wrong. What is the worst thing that happens? That the floating, NeXT-style main menu disappears? If that's a problem, the app should be solving it by not returning YES in applicationShouldTerminateAfterLastWindowClosed. If it really turns out to be a problem that an app should not solve, GNUstep could ignore the result of applicationShouldTerminateAfterLastWindowClosed in case a floating NeXT menu is used.
But otherwise -- why not simply honor the flag set for the NSWindow? :-)