Unlike Windows, GNOME and most other GUI's, OS X application programs do not all terminate if the main window (or all the windows) of that application are closed.
For example, fire up Firefox, Safari, Word, or most document based apps. Either click the red dot in the corner or type cmdW to close the window. You can see that the menu of that program is still active, and the program is still running. With OS X newbies, sometimes you will see dozens of these windowless zombies running and they wonder why their computer is getting slower.
With some document based programs, there is some sense to not terminating the application if it has no windows. For example, with Safari or Word, you can still type CmdN and get a new document window for whatever that application was designed to do: browse the web (Safari) or type a new document (Word).
Apple is mixed with their design philosophy on this. Some close on the last window closed and some do not. Third party apps are even more mixed.
There are other apps that do close when their red close button is clicked. System Preferences, Dictionary, the Mac App Store, iPhoto and Calculator do terminate when the sole or last window is closed. iCal, Address Book, iTunes, DVD Player do not terminate.
What I find particularly annoying is the applications that do not have a logical "New Document" or "Open" function yet they do not terminate when the document window is closed. Example: fire up iTunes or Address Book and terminate the main window. There sits a zombie with no window and no function other than manually selecting "Quit".
It is easy to close the application after the last window closes. Cocoa even gives you notification of that event. Just add this to your application delegate:
- (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender
{
return YES;
}
My question is this: Is there any reason I should NOT terminate my application after the last window closes? Why is this so variable on OS X software? Unless the app has a "new" or "open" or some other clearly understood reason to not terminate with no window open, the failure to terminate seems like a bug to me.
Per Apple's Human Interface Guidelines (a guide for Mac developers):
In most cases, applications that are
not document-based should quit when
the main window is closed. For
Example, System Preferences quits if
the user closes the window. If an
application continues to perform some
function when the main window is
closed, however, it may be appropriate
to leave it running when the main
window is closed. For example, iTunes
continues to play when the user closes
the main window.
In general, never close a document based application when the last window closes. The user will expect to be able to open a new document without relaunching the application, and it will confuse them if they can't.
For non-document based applications, you need to consider a few things:
How long does it take for my application to open? If it takes more than a second, you should probably not quit.
Does my application need a window to be useful? If your application can do work without windows, you should not quit.
iTunes doesn't quit because, as Anne mentioned, you don't need a window to play music (question 2). It is also not based on Cocoa, so it is much more difficult to close after the last window, especially since it allows you to open windows for specific playlists so there are an indefinite number of possible windows to be open.
In my opinion, Address Book does not need to stay open. This could be a left-over design decision from older versions of OS X, or it could be that someone at Apple just thought it was better to leave it open (maybe so you can add a contact?). Both iTunes and Address Book provide access to their main interfaces through the Window menu, as well as a keyboard shortcut (Option+Command+1 for iTunes, Command+0 for Address Book).
The main iTunes window can be reopened from the 'Window' menu. Mail.app has similar behavior. I can't think of any applications that close when the last window is closed, and as such I don't think there's a good reason that your app should behave that way (in fact, i'm surprised its not in Apple's user experience guidelines, it would really bother me!).
One reason why you'd want to close e.g. the iTunes main window but keep the app open is to be able to use the app as sort of a server for third party scripts/applications. I rarely use the main iTunes interface, but instead control my music with a third party app. I also write AppleScripts for other apps that I launch instead of interacting with that app's interface.
Related
I have developed a full-screen application that hooks into and launched by a 3rd party/client application. The problem is that the client application gets focus soon after it launches my application, with the result that although my application is full screen, and set to be on top, it does not receive keyboard input, as such the user has to click on it to bring it to focus, which makes for a poor user experience.
How can I restore focus to my application after the client acquires it?
If it matters, my application is written in C++ and has a QT UI.
Not quite the answer but the reason why my application does not have input focus. I'll let Charles Petzold explain (from Programming Windows 5ed, pg 213)
The Window that receives a particular keyboard event is the window that has input focus. The concept of input focus is closely related to the concept of the active window. The window with the input focus is either the active window or a descendant window of the active window -- that is , a child of the active window, or a child of a child of the active window, and so forth.
My Qt application is not spawned spawned by an active window and therefore does not have input focus. The solution therefore would be to parent my application to the active window. Unfortunately this is not straightforward in Qt, if at all possible.
Here is the Qt documentation:
http://doc.qt.io/qt-4.8/qwidget.html#activateWindow
http://doc.qt.io/qt-4.8/qwidget.html#raise
http://doc.qt.io/qt-4.8/qwidget.html#setFocus
Hope it helps when called after launch...
I'm a developer and a long-time Windows user with an obsession about making my system as convenient to use as possible.
Yesterday I thought about something that has always annoyed me in Windows and that I've taken for granted, and I realized that I have a better idea for how it could work, and I'm now wondering whether it's possible to tweak Windows to work like that.
The thing that annoys me is when windows steal focus. For example, I could be running an installer for some program. While it's working, I'll switch to my browser and browse, maybe entering some text into an email in my browser. Then suddenly the installer finishes and its window steals the focus. Now I'm in the middle of writing an email, so I might press a key that happens to be bound to a button on that installer, and then that button gets invoked, doing some action that I never intended to happen!
This is doubly annoying to me because I'm using a multiple-desktop program called DexPot, and when a window steals focus, it also brings itself to the desktop I'm currently on, which can be really annoying, because then I have to put it back into its original desktop.
How my ideal solution to this problem would work: Every time a window tries to steal focus, we intercept that, and don't let it. We show something like a toaster message saying "Foobar installer wants focus, press Win-Whatever to switch to it". If and when you press the key combo, it switches to the window.
The question is: Is there an easy way to tweak Windows to make this happen? I know very little about Windows programming. I do know AHK and if it's possible with that, that'd be great.
No, there isn't an easy way to add this behavior, but Windows tries to do this automatically.
In theory apps shouldn't be able to steal the foreground while you're actively using another app. Unfortunatly there are some scenarios where Windows can't tell the difference between legitimate user actions that should change the foreground and unwanted foreground-theft. The window manager generally tightens up the holes a bit with each new version of Windows, but also needs to make sure that apps can come to the foreground when the user wants them to, even if that desire is expressed indirectly.
For example, a process launched by the current foreground process can put a window into the foreground. This is necessary so that when a user launches a window from Explorer the newly launched process can open its main window. This permission only lasts until the next user input, so if an application is slow to launch and you start working on an email the app may lose its foreground permissions before it can use them.
See the SetForegroundWindow function documentation for a list of requirements for a process to be able to set a window into the foreground.
There are also apps which specifically make use of these requirements to steal the permission (by joining the foreground queue or synthsising user input to themselves), but I suspect in your installer scenario it is accidental.
I'm not sure what exactly is going on, but I suspect that the problem comes from the installer running as a service and accidentally stealing the foreground permission when it tries to launch the app on your current desktop.
It would be theoretically possible for an external process to hook into the foreground system to override this and show your confirmation toast, but it would be tricky to get right and would require significant low level code (I'd probably start with a CbtHook). It would not be possible in a scripting package like AHK (assuming you mean AutoHotKey) but would need to be native C/C++ code injected into every running process.
I am implementing a Cocoa application which supports the fullscreen mode. If the user quits while working on the fullscreen mode, I need to start the application in fullscreen mode,
While starting the application I check whether the application should start in fullscreen mode then call the toggleFullScreen: on NSWindow. Then the, application goes to the fullscreen mode and comes back to the normal window mode.
User can go to the full screen mode while working without any problem. Any tips on what's going wrong on this?
Make sure you really want to do this. Since Lion, there is a window restoration API that you should be using. See Any NSWindowRestoration examples? for how to use it. The caveat is that if "Close windows when quitting an application" in System Preferences is checked (which it is checked by default since 10.8), the window can only be restored upon reboot if the user chooses to do so.
If the user did not opt in for the window restoration setting throughout the OS across quitting applications, then generally you do not have to expect the window of your app to be restored for them. However, if you think you have a good reason otherwise, then I suggest invoking toggleFullScreen: after windowDidLoad: is called. I can only guess that you're calling it too soon and the window autosave might get in the way. It'd be helpful if you showed the relevant code.
Regardless, you should be implementing window restoration anyway and in the case of the window being restored by the API, you simply don't do anything.
My application is a debugger and I need to frequently switch the active process between a target application and my debugger application as the user steps from one line to another within their code. I am currently using the SetFrontProcessWithOptions(…, kSetFrontProcessFrontWindowOnly) call to accomplish this.
The problem I have is that the SetFrontProcessWithOptions() call returns before the application is fully activated. SetFrontProcessWithOptions() returns when the process becomes the active process, but before its main window has been brought forward and made active. If I call SetFrontProcess again too quickly to reactivate my debugger application, Mac OS X gets confused and the layering of windows becomes muddled. Visually, the wrong window appears to be active and keyboard and menu focus is directed to what appears to be an inactive window.
I have tried using GetFrontProcess() after calling SetFrontProcessWithOptions() to poll, but GetFrontProcess() immediately returns the PSN that my code has activated with SetFrontProcessWithOptions() even though that process's windows are not yet fully activated.
Does anyone know of a way to determine when an application has become fully active with its main window ready to receive keyboard input?
I'm dipping my feet into Cocoa for the first time.
Here's a simple question. OS X Lion supports Resuming of window state when an app is terminated and relaunched. Okay, good and fine.
But for document-based apps, can the same Resume feature also manage saving of window state when a document is closed and reopened later but without any quitting of the app? (In other words, can it manage each file's state persistently regardless of whether the app quits or not? Or do I have to manage it myself by saving the information in the documents' files?)
For instance, iWork '09 apps do do this sort of thing: if you close a saved document and reopen it, it will restore the window size, location, and scroller position. I don't know if it does this using Lion's Resume per se.
But, in contrast, OS X Lion's TextEdit restores windows when it is quit and restarted, but it does not remember window states when you close a document and reopen it. This makes me suspicious that using Resume without quitting might not be possible automatically (since maybe Pages keeps window states in its proprietary file format, but TextEdit doesn't since it uses plain text, RTF, HTML, etc. files).
I don't have access to the WWDC 2011 videos yet, and neither the OS X release notes, the OS X Application Programming Guide, nor the NSWindowRestoration API docs talk about this specifically.
So the question again: automatically remembering the state of a document window after closing and reopening it without quitting the app (like iWork does)...does Lion's Restore support this?
Thanks a lot!
But for document-based apps, can the same Resume feature also manage saving of window state when a document is closed and reopened later but without any quitting of the app? (In other words, can it manage each file's state persistently regardless of whether the app quits or not?
Not unassisted, no.
Or do I have to manage it myself by saving the information in the documents' files?)
Or somewhere else, yes.
My untested suggestion is to try using the window-restoration protocol yourself. When closing, send yourself encodeRestorableStateWithCoder:, then stash that data in your document (or wherever you want). When opening a document, if it has restorable state information, pass it to restoreStateWithCoder:.