Live data from Hacker News

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

news.ycombinator.com

461–470 of 573 posts

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

#461

Earlier quoted context omitted.

It's assumed Microsoft paid the troll toll (probably 2 decades ago). Linux is a complicated field to litigate anyone over a patent. It does happen just not easily compared to suing a big corp. But o god I found more cancer: https://patents.google.com/patent/US20110099512 Splitting one monitor into two virtual monitors is patented. Fuck you LG.

How can such general technologies be privately patented? What if someone patented the QWERTY keyboard?

QWERTY was patented, https://en.m.wikipedia.org/wiki/QWERTY

“Patent No. 207,559, issued August 27, 1878 to Christopher Sholes.”

https://patents.google.com/patent/US207559A/en

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

#463
post #330

Earlier quoted context omitted.

My favorite is how, if you have multiple windows of the same app visible, when you cmd-tab to that app, it moves all of the windows to the top of the stack. So if you want to switch between windows of two different apps, you better hide the ones you don't use.

My favorite "weird" thing common in X11 window managers is how they can separate the focus and the raising operations. On windows(and I presume mac) these operations are tightly linked. Why would you want to separate them you might ask? It turns out to be really useful to look at the window on the top and be able to type/control the obscured window underneath. On the one hand X11 sort of sucked with it's inconsistent…

> On windows(and I presume mac) these operations are tightly linked.

That's the default on windows, but it _does_ support focus-without-raising. In fact, it's literally called `Xmouse`: https://en.wikipedia.org/wiki/Xmouse

An easy way to enable it is to use Winaero Tweaker, but it's builtin Windows functionality: https://winaero.com/turn-on-xmouse-active-window-tracking-fo... (Just make sure "Enable window raising" is unticked).

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

#464
post #363
post #151

Earlier quoted context omitted.

The only Apple device I use is the laptop I was given for work, and I've always disliked that the button that would "maximize" the window on other OS instead makes the window "fullscreen" (getting rid of the menu and everything else that entails). I recently discovered that I am actually able to "maximize" by double-clicking the top bar of the window, but I have no idea if this is something that works by default or i…

Once I got used to gestures, I actually like macOS window management more than Linux/Windows for single monitor. It seems a bit clunky if you have multiple monitors Cmd Left/Right to change between fullscreen windows. Cmd Up Arrow to show all of the fullscreen windows. Using the trackpad, 3 finger swipe up to show all the windows. Either 3 finger or 2 finger swipe left/right to switch between them. When 2 windows are…

By requiring full screen windows that method is a non-started for those of us who don’t use Apple’s full screen. I find that it isolates app from each other too much. I’m almost always working with multiple apps at once.

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

#465
post #378

Earlier quoted context omitted.

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.

We've had "down to scroll down" on desktops back when smartphones were still Sci-fi.

The old scroll direction was tied to pushing the scroll bar button up to move the screen down. “Natural” scrolling ties the movement to the window content and makes much more sense once you get over the old habit. I took me about half a day to adjust.

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

#466
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 "…

It's much worse than Ubuntu or Windows though. I just want to snap a window to the sides. The macOS solution forces you to go full screen to snap.

That’s why there are dozens of their-party apps to provide keyboard or drag methods to snap and size windows. Rectangle, Moom, BetterSnapTool, and others give you different ways to doing window management.

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

#467
post #439

Earlier quoted context omitted.

> Well, because it has? This is absolutely not the same thing. The full screen feature on macOS is ok because it’s very well integrated with the 3 fingers gestures. But the fact snapping requires to go to full screen mode completely sucks, it’s unintuitive and requires too many steps compared to just « drag the window to an edge ». I agree with OP that Apple stubbornly refuses to implement QoL features for no good re…

Are they paid apps? Perhaps that's why. This way Apple can get a cut from the DLC.

And the paid ones are cheap, not a significant source of revenue for Apple.

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

#468

Earlier quoted context omitted.

Where should they be, and why?

On the right, because that's where most people are accustomed to find them. But they weirdest thing is that the buttons are colored instead of having meaningful icons.

you're right colors may be confusing if the user is color blind, I guess that's why the close is always the one on the left, the minimize is always the one on the middle, and the expand + extras is always the one on the right, so user can find what they want where their more accustomed to

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

#469
post #347
post #242

Earlier quoted context omitted.

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.

Windows default keyboard shortcuts: Windows + Left/Right Arrow to snap to half of screen. Add SHIFT to the mix to do the same, but transport it to the other monitor.

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

#470

Earlier quoted context omitted.

Apple has, for 20+ years now, wrestled with workarounds to the Mac's central UI blunder: making all applications share a single menu that's glued to the top of the screen. Every other windowing OS recognized that menus belong on their applications' main window frames, which makes the desktop an unlimited workspace. Apple should have made the same transition with OS X, but, in true Apple fashion, petulantly refused to…

I actually disagree strongly with (part of) this. Having a singular target menu I think is a good design decision (I used OSX in the past, but currently use windows+wsl at home, and linux for work). Having a singular menu position is consistent. It gives you an 'infinite' Y target...you just slam your pointer into the top of the bar and get menu options, and only have to care about X accuracy. The persistent menu on…

I respect your assertion, but I've heard this argument before.

"It gives you an 'infinite' Y target...you just slam your pointer into the top of the bar and get menu options"

Except that essentially nobody does this. Remember that you and I and other HN readers are not the general public, and the general public is not going to assume they can do this. Watch actual users. Not to mention that this only helps in the Y direction; you still have to position carefully to get to the horizontal item. Most people do not separate those two. I've been programming on Windows and Mac for decades, and I never ever "slam" the cursor to the top of the screen.

Also, "slamming" the cursor in Y will not work if you're using multiple monitors and one is above the other. For example, if you have a laptop on your desk with a big monitor above and behind it.

And any loss of "slamming" convenience is offset by the proximity advantage of a window-mounted menu. If the menu is on the window you're working in, you have to move the cursor less to get to it. On today's large, high-resolution monitors this can be quite a savings.

And finally, with the menu on an app's main window there's never any confusion as to which application's menu you're using. Again, with today's large screens, you are more likely to have multiple applications' windows up. It's hard enough to tell which application owns the menu without peering at the corner and reading a name, which is never a fast or intuitive solution and even worse if applications are presenting similar UIs (for example two graphics-editing apps).

And if you minimize an app and are left with a couple more on the screen... who owns the menu? Who remembers the last place he clicked? Why should you have to click around on apps' windows to swap the menu out to the one you want, and then roll all the way to the top of your 27-inch screen to use it?

Post reply on HN