Live data from Hacker News

Ask HN: Why does Apple refuse to add window snapping to macOS?

news.ycombinator.com

341–350 of 573 posts

Re: Ask HN: Why does Apple refuse to add window snapping to macOS?

#341

I always feel like Apple must have some grand 1000IQ concept for window management and I just don't get it. Stage Manager, Spaces, Mission Control, Expose, Window Zooming, Hiding, Minimizing (which is different from Hiding), Fullscreen/Splitscreen... yet the first thing I do is install a third-party window manager. I tried for months to go vanilla and get my head around the features. But why, why do fullscreen window…

They know that 90% of users use apps in fullscreen mode most of the time, or just higgly piggly stacked windows. Most people do not, most of the time, end up in situations where they are using two apps at once. Why do you think it took so long to get any window management at all into the ipad os?

They also know that power users have options in the 3rd party app market if they want more fiddly or opinionated window management and have decided to stay out of that fight.

Re: Ask HN: Why does Apple refuse to add window snapping to macOS?

#343
post #312

Earlier quoted context omitted.

The idea behind macOS window management is to not manage windows at all, instead letting them exist at sizes that fit their content in whichever position they land on your desktop, stacking and overlapping like papers on a desk, letting relevant bits peek through without requiring the entirety of their host windows being visible. Exposé/Mission Control are there when a window gets lost, and virtual desktops are meant…

It's a great way to waste both the screen real estate and the user's attention. MacOS has a number of interesting features in the kernel, and it has a reasonably good and highly uniform UI, with global shortcuts and all. But its window management is insufferable. Good thing there are utilities that try to help that. (I already forgot which, I handed back my last work-provided MBP in 2018.)

Most users of macos are fullscreen users. End of. Power users can find and write power user solutions.

Re: Ask HN: Why does Apple refuse to add window snapping to macOS?

#344

Can an Ask HN self-post be clickbait? Apple isn’t refusing to do anything. They just haven’t done some minor thing that you personally would like. The fact that you’re “shocked” by something as banal as “lack of window snapping” is kind of funny actually.

Almost everyone I know immediately installs a third-party app to handle windows when they get their Mac. That includes me.

Engineers know engineers. Engineers are often working in more than one app at a time (probably at least an IDE and some terminals). They get really anal about how their screens are set up for efficiency.

All my friends with non-tech jobs all seem to use just one app at the time and use macos fullscreen apps and switch between using the four finger sideways swipe.

Re: Ask HN: Why does Apple refuse to add window snapping to macOS?

#346
post #293

Earlier quoted context omitted.

> most apps can relayout and redraw their window in a tiny fraction of the time that animation takes Re-rendering to the same compositor target buffer (when you e.g. resize a window), and allocating new textures in (potentially) new formats under control of a new compositor target buffer, are different orders-of-magnitudes of work. Think about how much delay there is from the point you plug in an external display, to…

There is absolutely no reason for the common case of maximizing a regular window on the same display to switch texture formats or change resolutions or whatever else. That's silly. The compositor side of maximizing a regular window can and should be implemented in the same way that window resizing normally works, i.e. simply allocating one new screen sized texture to hold the application contents, which can be done i…

• Full-screened windows are virtual desktops with special UI treatment.

• Virtual desktops each have their own compositor texture "namespace", so that everything on the virtual desktop can be reformatted to deal with the screen beginning/ending mirroring/sharing, with the desktop being moved to a display that has a different color-space, etc. The copy of textures to new ones owned by the new virtual desktop, allows the compositor to be able to assume that a given desktop exclusively owns all the textures assigned to render on it. (It's the same set of engineering trade-offs as with message-passing IPC. Here the "messages" are textures and the "processes" are virtual desktops.)

• The "optimization" you mentioned exists and I already mentioned it. It was the old behavior. Go into Settings > Desktop & Dock and uncheck "Displays have separate Spaces." Congratulations, now you're using a non-per-virtual-desktop-texture-domained compositor. Enjoy going back to a world where putting your computer to sleep with no display attached, plugging the display in, and then waking it up, makes the kernel panic! But, if you do as a sibling commentor said and turn the animation down to nothing, you will surely notice the performance increase of full-screening windows.

> simply allocating one new screen sized texture to hold the application contents, which can be done in much less than one frame

Yes, this is what the animation that plays does at the beginning of the animation, on the existing virtual desktop — it creates a new, screen-sized texture, and renders the window being "resized to fullscreen" onto it.

Meanwhile, in the background, textures are being message-passed to a new virtual desktop.

> And if you think it's not worth the effort to optimize a case that typically happens every couple of minutes while people use macOS then I have to disagree in the strongest possible terms.

I don't know why you're full-screening windows so often.

> maximizing

Oh, maybe this is your misapprehension? Full-screen ≠ maximize.

Maximizing a window in macOS is what you get by option-clicking the green caption button. macOS calls this "Zoom".

Until Yosemite, this is the one and only thing the "maximize button" on a window did; "full-screened" windows didn't exist as a separate concept. There were just Spaces, with (maybe Zoomed) windows on them.

I — and pretty much every other macOS user I know — regularly uses zoomed (or just resized to be mostly zoomed) windows, but very rarely uses full-screened windows.

For a lot of reasons, full-screen windows on macOS are really inconvenient. They hide the menu bar; they cause some apps to make a ton of their UI elements inaccessible; they make "overlay" apps (e.g. iTerm's "quick access" theme) inaccessible; they make the Dock require a double-bump to access; they make things you open from the Dock open randomly on some other virtual desktop; they make it impossible to drag-and-drop things onto the full-screened window from another window; they make it impossible to grab the window itself with the mouse to move it to another display (instead requiring you to move the virtual desktop the window occupies to the other display); they don't respect application window grouping in Mission Control, so you inevitably "lose track of" the one window you decided to fullscreen; etc. (Also, until more recent macOS versions, full-screened windows couldn't even display modal dialogs or palette windows.) Basically, they take everything that makes macOS more useful than iPadOS and toss it in the trash.

Using windows zoomed rather than full-screened, meanwhile, has none of these problems. (If you want a zoomed window on a separate display, then make a new virtual desktop, move the window there, and then zoom it. I think Magnet has a hotkey for this.)

Re: Ask HN: Why does Apple refuse to add window snapping to macOS?

#347
post #242
post #141

Well, because it has? Hover over the green stoplight, you get a popover with fullscreen options. Press Option and the fullscreen options mutate into snap left/snap right/zoom. These can also be found in the Window menu. Again, press option to mutate the fullscreen ones to snap. And since these are menu options, one can set any keyboard shortcut of their choosing through the keyboard shortcut prefpane+. So it is not "…

That's awful. Instead of windows where you can BAM drag a window to one side and snap it in 0.2 seconds, you have to hover over the window, wait a second, press option, wait .1 second, figure out which option you want, mouse over to it, then finally click it. That's insane.

In terms of discoverability, yes, that UI is super awkward and feels tacked on.

In terms of speed, keyboard shortcuts take the cake any day as they make snapping a 0.0 second affair.

Re: Ask HN: Why does Apple refuse to add window snapping to macOS?

#348

Can an Ask HN self-post be clickbait? Apple isn’t refusing to do anything. They just haven’t done some minor thing that you personally would like. The fact that you’re “shocked” by something as banal as “lack of window snapping” is kind of funny actually.

I am a Mac user for many years now. The first thing I always set up is Magnet. A third party app that allows me to have proper window management. So yes, in my opinion it really is shocking if even Windows manages to have a better user experience in something so basic, for more than 10(?) years.

I just bought it and am blown away. Thank you, sincerely, for your comment.

Re: Ask HN: Why does Apple refuse to add window snapping to macOS?

#349

Earlier quoted context omitted.

It's weird that Apple is obsessed with gesture-oriented interfaces—even for things that really don't call for a gesture—but when there's a super intuitive gesture pretty much everyone else has settled on they decided instead to rely on a hidden context menu.

Like scroll direction, having a sim card in your phone, using accepted standard cables, giving users access to their own files, using standardized file formats, etc. These guys abuse their users and somehow they believe Apple cares about them. Not sure when everyone will wake up and realize that arbitrary change isn't better than expected behavior. I guess when the industry points "AI" at generating OSes then Apple w…

The default scroll direction on macOS absolutely makes sense from a UX perspective. On a phone, you scroll up by physically touching the same display your content is on, so you have to move your finger down on the screen, which makes sense on phones but not on computers where the content is separate from the touchpad.

Re: Ask HN: Why does Apple refuse to add window snapping to macOS?

#350

Earlier quoted context omitted.

IME it's the opposite

Last time I’ve tried Windows, there were ads in the start menu. And when I tried Ubuntu, they switched from Gnome to Unity, so I ragequit. Also Ubuntu had ads for Amazon in its start menu.

I would recommend openSUSE or Fedora then. No reason to use Ubuntu
Post reply on HN