Just looked at 1.3.12 and find:
After deleting (or "initializing"--tried both) config Audacity defaults to closing when last window closed on Windows. Here is the relevent code:

src\prefs\GUIPrefs.cpp line #81
// Code duplication warning: this default is repeated in Project.cpp
// in the destructor.  -DMM
#ifdef __WXMAC__
   const bool bQuitOnCloseDefault = false;
#else
   const bool bQuitOnCloseDefault = true;
#endif
// End code duplication warning

[... line #134]
      S.TieCheckBox(_("Closing last window &quits Audacity"),
                    wxT("/GUI/QuitOnClose"),
                    bQuitOnCloseDefault);

Find all "bQuitOnCloseDefault", Match case, Whole word, Subfolders, Find Results 1, "Entire Solution", "*.c; *.cpp; *.h"
  D:\audio\Audacity\SVN\src\prefs\GUIPrefs.cpp(84):   const bool bQuitOnCloseDefault = false;
  D:\audio\Audacity\SVN\src\prefs\GUIPrefs.cpp(86):   const bool bQuitOnCloseDefault = true;
  D:\audio\Audacity\SVN\src\prefs\GUIPrefs.cpp(136):                    bQuitOnCloseDefault);
  Matching lines: 3    Matching files: 1    Total files searched: 1480

I do see that DMM's comment seems no longer correct and might be removed.

--Ed

So File->Close is supposed to do something different than clicking the "X" in the upper right sometimes? I guess that would make sense to me in an MDI-style program where each document has an inner close button (File->Close would always act the same as the inner close button). I think that's the case with MS Word, though I don't have it here to test with. We don't have an MDI or an inner close button, so I tend to think File->Close should do the same thing as the "X" button in the titlebar. As we can have multiple windows but don't have an MDI, we're more like Firefox. And in Firefox every way of closing the last window quits the program (on Linux, at least, and probably on Windows).

I agree that the OS-initiated close methods (on Windows: clicking the "X", taskbar context menu, Alt-Space menu, shutdown notification) should cause a quit on the last window, and it's wrong for a preference to mess with that.

I'd personally get rid of the preference entirely and make any method of closing the last window quit the program (except on Mac). That's consistent, simple, and clear to users and easy to implement and understand for us. No matter what we choose some users will complain. If this is OK I can probably get it done today.

If we must allow File->Close to do something different then there's a whole other set of questions... let's jump off that bridge when we get there.

I agree that theoretically File > Close not quitting seems more obvious in multi-document interface (MDI) apps than single document (SDI) ones. However, Word is an SDI multi-window app (like Audacity) which behaves exactly as the complainants want Audacity to (File > Close on last window clears to a new workspace, but is then greyed). I think the comparison with document apps is more relevant to us than browsers (though yes some users would like Audacity to be a tabbed MDI app). I think clearing to an empty project is very useful, and something that more users want to do than not. 

If we went with File > Close on last window always quits (except on Mac), how can users clear to an empty project without quit and restart? They can close all their tracks, though this is not an obvious way of clearing the workspace because of the prevalence of File > Close doing this in document apps. But even if they do that, they are still in the same project with the same history, taking up disk space. 

So I'm still very strongly in favour of File > Close clearing to an empty project by default. If we keep a preference, "closing last window quits" should be unchecked by default on all platforms (once system close methods are allowed to quit on Windows/Linux). I agree a minority may then grouse that File > Close doesn't quit, so that leaves a judgement as to whether there should be a preference to appease them.

If we went down this route, then we have cross-platform default behaviour that File > Close on last window always clears to empty. On Windows and Linux, system close methods on last window *always* quit - no choice about it. On Mac, I'm not  clear what happens if you hit the red circle with that preference unchecked - does Audacity still quit? Either way, if we go with what I'm suggesting I assume we just leave Mac alone as there is zero issue there.

On Mac, if the "Closing last window quits Audacity" pref is checked, then closing the last window quits Audacity. Otherwise it closes the window but the application remains open and active (in control of the menu bar -- there are three menus available, and from there you can start a new project). I think this is exactly how it should be on the Mac.

The difficulty of having File->Close clear out the last project and start a new one is that there are basically two commands. I'll call them "close project" and "close window". Fortunately, I think all the cases where we want "close project" will come through our command manager (the menu item, Ctrl+W) and all the cases where we want "close window" come straight from OS events (including Alt+F4 -- for some reason I had thought we handled this through the command manager, but I checked and this is not the case). So I guess we can have a distinction that's reasonably logical.

I'd still prefer to get rid of the preference, because (a) lots of preferences mean more cases that should be tested but probably won't be, leading to bugs like the endless loop on Windows shutdown; and (b) if there are in essence two different "close" commands then it becomes difficult to word it properly.

(In reply to comment #4)
OK for Mac, then. 

Thinking about it more, I feel removing the preference for Windows/Linux and letting File > Close on last window always quit will likely make the support problem even worse - the people who want that to clear to empty will now have to restart. Personally that would drive me nuts. I think the feature is too useful, and too "expected" on Windows, to throw it away. 

I'm no lover of that pref in itself though and wouldn't mind getting rid of it if File  > Close on last window always cleared and the OS commands always quit. We could then possibly word the pref better for Mac.
 
Alternatively, how about removing the preference so that File > Close always quits but have an explicit Audacity command to clear to empty. Does that provide extra one-step functionality on Mac that makes it worth doing? If not, I doubt it's worth the support headache of telling non-Mac users that the preference has moved into a menu command. 

If testing is a problem, I'll test till the cows come home, this wastes so much of my time as it is now.

Mac: Audacity's default on Mac matches traditional Mac behavior exactly. There's no need for a preference or a second command. I'm hardly an Apple fan but I've got to hand it to 'em: they got this one right a long time ago. I wish it were so easy everywhere.

Win/X11: It's harder because there's no standard behavior. If you're OK with the following then I am: (a) Remove the preference because preferences are a pain and it's hard to word this one in a way that accurately represents reasonable behavior; (b) System-initiated close always closes the window, quitting Audacity if necessary; (c) File->Close (and its keyboard shortcut) always closes the project, and just clears the window if it's the last project.

Sorry for taking up time with this -- it's not a straight-up coding error and I don't want to just go off making UI decisions on my own (that usually makes people angry).

Al wrote:
> Win/X11: It's harder because there's no standard behavior. If you're OK with
> the following then I am: (a) Remove the preference because preferences are a
> pain and it's hard to word this one in a way that accurately represents
> reasonable behavior; (b) System-initiated close always closes the window,
> quitting Audacity if necessary; (c) File->Close (and its keyboard shortcut)
> always closes the project, and just clears the window if it's the last project.

(a) - OK
(b) - OK, the quit being done when it's the last window. Note it's possible to aggregate Taskbar buttons on Windows rather than having a separate button for each window. This happens by default on XP if I recall correctly, and clicking that aggregated "close" on some multi-window apps will close all the windows and run through any prompts for each. Is that what we want, or to have to repeat the close for multiple windows as you do with [X]?      
(c) - OK

I'm not clear, are we keeping the pref for Mac? I believe it's misunderstood, so hardly ever used except by some Win > Mac converts.

(In reply to comment #7)

(b) As for the "aggregated" close -- in Win 7 this is labeled "Close all windows" and it sends a close event to each window. So we don't really have a choice there, it will close 'em all. My guess is it works the same way in earlier versions, though I don't know for sure.

Mac: no pref.

I should have this done by some time Monday, maybe sooner.

(In reply to comment #8)
On Win XP now: in fact by default there are individual Taskbar buttons for each window, though most tweaking apps like MS TweakUI allow you to group buttons. With the Audacity preference "Closing last window quits..." checked, the Taskbar button "Close Group" works correctly to close three Audacity windows, prompting for each window close and quitting on closing the last one. Doesn't work for all Windows apps here, so I presume that's the fault of the app.

Declaring fixed. Tested by me on Ubuntu, Win 98SE, XP and 7. No complaints made on Mac.