This is an interesting app in terms of illuminating expectations of different user groups.
Back in 2010 when I got my first MacBook, the app not closing when the window closed was alien to me as someone who had only ever used Windows. But that discomfort only lasted a few months, and I grew to strongly prefer the distinction of “this app is running” and “this app is has a window open” + value the difference between Cmd-Q and Cmd-W.
I remember one OS update made the app closing behavior the default, and I had to go learn where the setting was to undo it; a subsequent OS backtracked on that. The distinction is less meaningful these days with NVME making apps launch much faster than spinning 2.5” drives, but stuff like Photoshop still has a long startup time.
Why do you prefer having an app running (and owning the sole menu bar) when it has no GUI on screen?
I switched to Mac 20 years ago (when I started a decade-long stint as software engineer at Apple), and I still DETEST this behavior. Why the hell do I want some application that I just "closed" to continue owning the menu? Of course, this indicts the Mac's single menu bar, glued to the top of the screen. That mistake should have been fixed with the transition to OS X, but nope.
A related issue is Apple's half-assed implementation of Alt-Tab-style app switching. I was pretty impressed that they added this Windows-style feature, but less so after finding that it doesn't restore minimized apps. Again, why do I want to switch back to an app but not restore its UI? Fortunately there's a utility for that: Alt-Tab. https://alt-tab-macos.netlify.app
It can also create a window for applications that lack them when you switch to them; this is a huge boon for Finder.
If its a app with a document model, it kinda has to?
You close a word document, and then open another (through menu item), it shouldn't close the app in between. Also its not uncommon for me to close all the browser windows but leave the browser running, so that I can easily cmd-tab there and open new window. Yes, you can kind of workaround with some MDI style window, which you then would have to hide when not wanting to quit, but feels a bit unnecessary.
In the category of "single window apps", I wouldn't want my music to stop playing just because the gui of spotify is not visible. Granted, Hide might be a better option than closing the window, depending on if the app being active is useful without the gui. With spotify in particular, I would expect space to act as a play/pause even without gui visible, though annoyingly it seems they have not implemented it like that (apple music does).
I've never encountered any confusion of this sort with Word on Windows, nor with Windows's window-management in general.
Nor have I encountered music apps ceasing playback just because their window is minimized... with one exception: Apple Music stops playback if you minimize it when a music video is playing.
I think the issue on Macs is down to Apple forcing all applications to share a single menu, instead of putting the menu on the application's main window frame the way every other GUI evolved to. A single menu glued to the top of the screen reduces your entire desktop to one application's client area, instead of an open workspace for many applications. This weakness has historically degraded the Mac's multi-monitor experience too.
Fortunately, most Mac apps have finally abandoned their penchant for barfing out a flotilla of windows all over the screen, and gone to a modern single-window design.
Apple has attempted several workarounds for the window-management problem, like "Exposė" and "Stage Manager" and "Mission Control." The first thing I do with a new Mac OS install is disable all those irritating hotkeys... and STILL find windows randomly zooming out to a gallery sometimes.
I like the Mac concept of the global menu bar that represents which application is focused thus, for example, which app will receive hot keys including cmd-Q.
When you get used to it, it’s jarring to go back to Windows and realize you don’t even know the name of an unfamiliar app that is open much less which one will be alt-f4’d if you were to press it.
Why should you have to look for the name of an application to see if it's focused? If that's true, the GUI is a failure.
Knowing which app has focus does not require the entire system to be limited to a single menu. It simply requires proper visual feedback to SHOW the user which window (and attached menu) is active.
Hahahah, there it is, the once-inevitable "Fitt's law" trope.
People citing 'Fitt's law" to defend this dumb menu design love to ignore the big D in that "law." And what does the D stand for? DISTANCE.
Fitt's law dictates that the menu should be on the application's main frame, because that's closer to where the user is working (thus minimizing D). That's more true today than ever, as screen sizes and resolutions have reached new heights.
It's the ratio of the distance and the size what matters, not the distance itself. In this sense the menubar has infinite size because you cannot move the pointer forward it, thus you cannot miss it.
Fitt's law was for mouse (not trackpad) and for small screens where the menu was near the window. Both of these are for less common now.
Also now we have Search function within menus.
Nowadays it's easier to navigate menus with keyboard than pointing device.
> Why do you prefer having an app running (and owning the sole menu bar) when it has no GUI on screen?
Here's a story from when I was using Windows for work after using Macs for ages. I had one folder in Sublime Text open, and I wanted to close that window and then open another one. So I hit the [X] button in the corner, which closed the window, and then I instinctively went to the global menu bar at the top of the screen to go to 'File › Open' to open my new window. But of course, it wasn't there, because closing the window also got rid of my ability to access the menu bar.
And then I opened Sublime Text again, and it re-opened with the old window I wanted to get rid of.
This is why, like others in this thread, I've grown to really like the application-vs-window separation. Having a menu bar on each window, and having programs close themselves when they get down to zero windows, means I have to do my operations in a certain order (I have to open my second window before I can close the first one, I can't do it in either order) and use a UI hierarchy that I don't think makes sense (I have to use the menu bar of an existing window to open a new window, even though that operation has nothing to do with that window's contents).
I think the reason people might prefer it is because it avoids the startup time. The parent mentioned Photoshop - an already-open Photoshop with no windows can open up a new window instantly, whereas a closed Photoshop will have to go through the whole startup process again.
This, pre-SSDs, used to be a much, much bigger deal. Now it's not as big a deal, but if you've been using Macs for 20 years surely you've felt the difference between opening a window of an already-open app vs opening an app from scratch.
I personally love that I can have all the apps I want permanently open on my Mac, and never have to experience the delay of anything launching. A new window just pops up instantly when I wanna interact with an app. It's great.
This doesn't require that the dismissed application still have control of the menu, however.
It's annoying when you momentarily check a new E-mail message, minimize Mail, and then try to zoom the Web page you're looking at... only to find that it doesn't work because Mail still has control of the menu. And to fix that you have to click on the browser's window, which is a hypocritical admission that the GUI is the expected means of interacting with an application.
That depends on the application. Most modern applications (fortunately) shun the pile of floating windows that dominated Mac application design historically. For document-centric applications, developers can implement MDI style or tabs and keep their app tidy.
I rarely find that momentarily checking an email changes the zoom level that I prefer on a web page, but if I did, I think Command-Tab Command-+ would allow me to change it quickly.
I much more frequently quickly check an email, close it, and then want to send a new email than I want to change the zoom on a web page as my next action.
The zoom example was only that: an example of an attempt to interact with the "active" application on the screen that fails because the menu does not correspond to the application that's being shown.
Feel free to replace the Mail-&-browser example with two applications that YOU might want to bounce between.
I’d prefer that application stay open so that I can accomplish my next task and that Command-N does “make me a new one of what I was just doing, not a new one of the thing I was doing before that”.
It's a different model to what you are used to and IMHO more flexible and powerful. If you try and keep operating in a manner learned on a different model you will inevitably be frustrated.
OK so now we have to issue a series of hotkeys (and then another series to undo them) in order to achieve what only requires half those actions on other systems.
There has been no evidence provided to show how this design is "more flexible and powerful," since all the same options exist on Windows, which ALSO offers other options that require half the steps to achieve app-switching.
That’s why I just cmd+(shift+)tab and cmd+(shift+)`. No need to use a mouse and it doesn’t bother me that the window stays in the background. Most apps run in full screen anyway. Same with windows: alt+tab (citrix…) is the way to go.
I haven’t minimised a window in months. For those special needs, there’s expose.
A window does represent an application on some systems. It doesn't on the Mac, because of the aforementioned single-menu problem. It turns your entire screen into the client area for a single application, whereas other windowing GUIs treat the desktop as an infinite workspace that can show many applications.
That makes it EASIER to deal with "each independently."
Funny, I really like the macOS approach. I could make a similar list, but with Windows on the "why would you want that" side. Here's what I like about the macOS approach:
- If an app is open, load times for new windows are instantaneous; I have a M2 and the difference between a new window for an app that's open and launching an app is still pretty noticeable for most apps. It's definitely noticeable on my Windows PC, and it's mildly annoying.
- I don't have to keep track of what's running: A new or main window for a frequently-used app is always just Cmd-Tab, Cmd+N/0/whatever, regardless of whether I already have five windows open or none at all. Allows me to keep the dock hidden too since I typically don't need to see what's running and what isn't.
- Cmd+Tab is more like a context-sensitive window launcher than a list of windows for me, one that I can navigate quickly by keyboard; select an app, hit h for hide, q for quit, up-arrow to see all its windows. If I might need an app, like CaptureOne, it's in the Dock; if I'm actually likely to need it, like Mail, it'll be in Cmd+Tab (possibly autostarted), add/remove from/to the latter is really low-friction (Cmd+Space, Cmd+Q), macOS optimizes resource usage so running apps don't bog down the machine. I find that a lot more useful than the simple list of windows I get via Windows Alt+Tab. Grouping windows per app keeps the size of that list manageable, though there are cases when that gets in the way somewhat. That's true for Alt+Tab too, it gets crowded real quick, requiring a lot more tab-ing.
- Another advantage of the macOS paradigm: Less background agents; seems every other app on Windows has one. By far not as frequent on macOS since you don't necessarily need a background service to speed up starting times or run updates; I see those things mostly in apps that have been sloppily transplanted from Windows, or that actually need to do meaningful work when the app isn't running, like Little Snitch.
- Cmd+Tab does restore hidden windows, just not minimized ones. A distinction that Windows doesn't have, IIRC, but one that I find useful. Cmd+H is for getting things out of sight, minimize is for getting things out of the way completely. Windows minimize is more like hide, but for individual windows.
- I like the single menu bar; every app has one, and it's always in the same place, and it's always the foremost app's and even if I don't have an active window right now, I can still run updates, open files, open windows, ... without a launcher screen or similar cludges. I think Windows integrates something similar into a task icon popup these days. I've noticed many modern Windows apps have their own ideas about what a menu should look like, how you access it, whether you need one in the first place, whether you should be able to navigate it by keyboard. IIRC even Office does that, not a fan. On macOS you can assign a keyboard shortcut to every menu item of any app via System Preferences, you can search menu items, there are apps that render nice overlays with the available functionality and keyboard shortcuts based on the menus, all of that's up to the individual app on Windows (and it seems most are moving towards mouse-only navigation there). The macOS menu system is also pretty neat for accessibility and automation. I've built apps (not for wider distribution) that consisted of just the menu and didn't even have a real UI, because that's enough for some things, super quick and easy to build from non-Apple languages, and trivial to automate.
You seem to feel like macOS should be a carbon copy of Windows w.r.t. window management, but it's not, macOS apps are pretty different conceptually than Windows applications, and different states are supposed to mean different things, interactions aren't supposed to work the same, different compromises in a lot of places. Both approaches work and have a theoretical underpinning that I think is sound, it's just different, and I think it's nice to have options. You want the Windows way of doing things? I guess Windows is always going to do the best job at being Windows, so use that? Unless you're still at Apple, then I guess you're out of luck.
> It can also create a window for applications that lack them when you switch to them; this is a huge boon for Finder.
I agree it's annoying that Finder doesn't do this (somehow it's almost the only app where that behaviour annoys me). I probably could do something like that in Hammerspoon, too. Hmmmm.
Most of what you cite here isn't dependent on the single-menu design, however. Application startup time, the way things are listed in Alt-Tab galleries, "background agents..." Valid beefs, perhaps, but none is related to the single-menu issue.
"I like the single menu bar; every app has one, and it's always in the same place, and it's always the foremost app's"
That's simply not true. I can have one application on my Mac screen, Safari, and yet the menu belongs to Mail. That's just dumb.
You do correctly call out one of the (sadly plentiful) regressions in Windows: the sudden deletion of the standard menu from many applications' window frames. It was just as "findable" as the Mac's for most of Windows's existence, but now it's just often... missing. WTF? The Office UI is an absolute shitshow, and the rest of Windows has been circling the drain for years.
Therefore no, I don't think the Mac should be a copy of Windows. I just hate the single-menu design and the pervasive UI clumsiness that has emanated from it. Any mode of operation it offers can also be offered by any other windowing GUI, minus of course the glued-in-place single menu... actually, you can mimic even that by maximizing your applications and Alt-Tabbing between them.
> > "I like the single menu bar; every app has one, and it's always in the same place, and it's always the foremost app's"
> That's simply not true. I can have one application on my Mac screen, Safari, and yet the menu belongs to Mail. That's just dumb.
Right, it's the one belonging to the active application, not the foremost one (though, most often, the two will be the same). On Windows, an application and its main UI are very tightly coupled; macOS sees the two as separate entities, and I think Mail is a good example for an app where that totally makes sense, since that way I can open a new e-mail dialog without going through the main UI; just Cmd+Tab to Mail, Cmd+N, or Cmd+0 if I need the main UI, and if I don't explicitly close it or minimize it (and Cmd+H instead or just Cmd+Tab back to the browser or whatever) it'll come right up when I Cmd+Tab to Mail. I think that's a pretty smart way of doing things.
Similarly, with Finder, I can just hit Cmd+K for the "Connect to Server" dialog, Enter, and I'm on my NAS since it remembers the last server address. No unneeded Explorer window popping up, no mouse required, pretty quick. I can close the current browser window and keep a minimized window with a few tabs I'll need for an activity later this evening, because the browser doesn't have to have a UI just to be active. Those tabs sit down there and out of the way, but I still have them and their state. Windows would force the minimized window to the foreground when I Alt+Tab to the browser, and it's hard to think of a system-wide scheme that does what you want, but still allows for this. I think actually the macOS paradigm is quite a bit more flexible.
> Therefore no, I don't think the Mac should be a copy of Windows. I just hate the single-menu design and the pervasive UI clumsiness that has emanated from it.
How tightly an app and its UI are coupled has nothing to do with the single menubar. It does sound like you have a very strong preference for the way Windows does things, and you expect things to work that way, and where they don't, you hate that. Why don't you just stick with Windows? After all, the great thing about having options is that I can have the macOS way and you can have the Windows way and we can all be happy.
I have been having the opposite working on Windows recently. I have gotten used to closing windows (like Visual Studio Code) because it reopened to a directory I didn't want and doing Command+N to open a new window. When I do that in Windows, I have to reopen the whole app and the window I didn't want pops up again.
Back in 2010 when I got my first MacBook, the app not closing when the window closed was alien to me as someone who had only ever used Windows. But that discomfort only lasted a few months, and I grew to strongly prefer the distinction of “this app is running” and “this app is has a window open” + value the difference between Cmd-Q and Cmd-W.
I remember one OS update made the app closing behavior the default, and I had to go learn where the setting was to undo it; a subsequent OS backtracked on that. The distinction is less meaningful these days with NVME making apps launch much faster than spinning 2.5” drives, but stuff like Photoshop still has a long startup time.