5 ms·
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-lo
by BuckyBeaver 4y ago
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 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.
- scoopr 4y agoIf 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).
- BuckyBeaver 4y agoI'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.
- hombre_fatal 4y agoI 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.
- pantulis 4y agoANd not to mention Fitt's Law.
- hgsgm 4y agoFitt'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.
- BuckyBeaver 4y agoHahahah, 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.
- pantulis 4y agoIt'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.
- BuckyBeaver 4y agoWhy 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.
- pocketarc 4y agoI 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.
- BuckyBeaver 4y agoThis 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.
- sokoloff 4y agoI 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.
- BuckyBeaver 4y agoSeriously? 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.
- deleted 4y ago[deleted]
- dividedbyzero 4y agoFunny, 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.
- jachee 4y agoA window isn’t an application. Just like a terminal isn’t an OS, a function isn’t a program, a web page isn’t a web site. Being able to deal with each independently has value.
- BuckyBeaver 4y agoA 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."
- jachee 4y agoYou seem to really hate the single menu… How often are you interacting with the menus of multiple applications simultaneously?
- cytzol 4y ago> 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).