up vote 4 down vote favorite
3
share [g+] share [fb]

I know it's just a pet peeve, but I hate it that Mac OS X's Preview.app stays open when it has no windows open. Is there any way to make it close when its last window is closed?

Since I don't see any option inside Preview to make that happen, I imagine that the answer might be applicable to other programs that have similar … idiosyncrasies.

I realize that this is not outside the OS's interface guidelines. That is, I recognize that this isn't a bug that will be fixed. I'm wondering if there is some way to automatically close selected GUI applications that have no windows open.

link|improve this question
50% accept rate
feedback

4 Answers

up vote 8 down vote

In short: No.

--Answer stops here. Everything following is just my attempt to explain why.

What you are experiencing is the Mac philosophy of how applications should behave. Those who are closed after the last window dissapears are not behaving to Mac Interface Guidelines (though there are a lot out there). // Edit: This is not entirely correct, see posts below.

It has been that way since the very first Mac System (in 1984). I guess it'll stay with us for another 25 years to come. Maybe app devs will allow us to set that in the preferences.

Until then it helps getting used to Command-Q (the Apple key and q) to quit each and every app - and Command-W for just the active window.

link|improve this answer
My personal opinion as a comment: Working with both platforms every day: I got used to it. Doesn't make that much difference at all and - as always - there are two sides to it. While the app is running, each subsequent start is super-extremely-quick. Those apps that I use just once in a while could just as well be closed right after I use them. I got used to Apple-Q/Apple-W on the Macs much faster than Alt-F4/Strg-F4 on the Windowsers. – Wolf Oct 11 '09 at 16:26
3  
One can also press Q while using Command-Tab to switch applications (thus while still holding down Command), to quit the application that is currently highlighted in that application switcher. – Arjan Oct 11 '09 at 16:32
+1 for Arjan's comment. It's an amazing way to close a huge number of apps at once. You do this whenever you need to free up some memory. – Yar Oct 11 '09 at 17:22
Actually, using the Application Switcher is the only time that open applications bother me. Too bad hiding applications does not keep them away from the application switcher. – Arjan Oct 11 '09 at 18:03
What really, really annoyed me was that minimized apps showed up in the app switcher, but wouldn't be restored if choosing them. That I found very inconsistent. Just recently - after literally years of usage - I came across pressing ALT while switching to the (minimized) app would restore it. Hooooray!!! – Wolf Oct 11 '09 at 20:46
show 3 more comments
feedback
up vote 3 down vote

Actually Wolf, it's not against the Mac Interface Guidelines to quit after the last window is closed. Case in point: System Preferences.

link|improve this answer
2  
"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." developer.apple.com/mac/library/documentation/UserExperience/… – Richard Hoskins Oct 12 '09 at 1:41
@mclaughlinj: I stand corrected. – Wolf Oct 12 '09 at 20:19
feedback
up vote 1 down vote

I wrote an AppleScript application to do this for you.

In brief, it checks what applications are open, gives you the option to whitelist apps to be excluded from auto-quit, then every 60 seconds, quits all applications (that it can, due to limitations).

To alter the whitelist while it's running, click the icon in the dock for the selection dialog to reappear.

To quit, right click the Dock icon and choose "Quit"

AppleScript source and Application: http://files.me.com/kioarthurdane/6kjl9k

link|improve this answer
Seems like a good idea, except it doesn't work. I had to change "name" to "displayed name" in refreshWindowedProcess() to keep it from asking "where is this application", but even then it doesn't seem to ever quit anything. – wfaulk Oct 27 '09 at 3:37
What version of OS X are you using? I wrote my script under Snow Leopard, not sure if there have been major changes to AppleScript. – Kio Dane Oct 27 '09 at 17:00
Nevermind, OmniGraffle Pro just did it to me. Very funny those cases were the name in Finder is not the actual file name... I'll see if I can write a correction to this using the bundle identifiers instead. – Kio Dane Oct 27 '09 at 17:06
Updated using bundle identifiers instead of application name (which can be different than the application's filename). In the source, there's a note about two lines commented out that will report the list of windows in each bundle identifier. I notice that many applications report having at least one window open despite no visible window being open. NetNewsWire is one such app having a long list of windows even after the main window is "closed". The Hit List is another app that retains it's single window is always open. – Kio Dane Oct 27 '09 at 19:15
Count of Windows = 0 seems the most obvious way of detecting your state for quitting, but this does not seem to do the job for all apps. Come up with your own conditions to add to my code. Since not all applications have an AS dictionary, it will be hard to check those apps for any other conditions (let alone time consuming to make a separate rule for each one). I'm more inclined to agree with the other answers given of "It's part of the Mac Culture to have a headless application still running" Unless it's doing something, it's not gonna be taking up much CPU or physical RAM. – Kio Dane Oct 27 '09 at 19:16
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.