Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

471–480 of 573 posts

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

#471

Post by rstevens333 »

rcarmo wrote: post #51
ralfd wrote: post #41

My go to example to explain the One True Mac Way of Window management is the “The many windows of John Siracusa” podcast from ATP a few years ago. The relevant discussion starts at 1:33:00 https://atp.fm/episodes/96 Siracusa, who grew up as a (classic) Mac user, explains his tiling and overlapping habits to Arment and Liss, who grew up as Microsoft Windows users and later switched, and they gasp in utter horror, shoc…

The extinction of OS 7 (platinum) roll-up windows is something many people miss.

[flagged]

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

#472

Post by ShadowBanThis01 »

0xr0kk3r wrote: post #459
ShadowBanThis01 wrote: post #394

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 hate wasting ui space by forcing every application to use their window real estate for a menu bar. There should be only one menu bar in the same location that changes when the context changes. It’s one of my favorite aspects of macOS.

It doesn't waste space. Windows can overlap; it's one of the fundamental aspects of windowing GUIs. Having a single menu glued to the top of the screen permanently wastes THAT space.

Strange argument.

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

#473

Post by ShadowBanThis01 »

ChrisLTD wrote: post #449
ShadowBanThis01 wrote: post #391

Earlier quoted context omitted.

Except he presided over an OS that shunned the evolution that every other OS arrived at: Menus belong on applications' main frames, not glued to the top of the monitor screen. This is why Mac apps have a long history of barfing out an irritating flotilla of windows all over the place. Mac OS turns the entire screen into the client area of ONE application, whereas other GUIs can treat the desktop as an infinite worksp…

Menus at the top of the screen provide consistency between applications. You don't have to wonder if an application's menu items are behind a hamburger menu, or missing entirely (I'm looking at you Obsidian for Windows). Also, having menus (or anything else really) at the edges of the screen make it easier to move to with a mouse. You can throw your mouse cursor toward the edge without worrying about the distance, be…

"Menus at the top of the screen provide consistency between applications. You don't have to wonder if an application's menu items are behind a hamburger menu"

Menus' consistency has nothing to do with where they are positioned. You're talking about bad design. You can just as easily have dumb, non-standard affordances at the top of the screen... you see it on iOS all the time.

And the "slamming the cursor" argument is countered by having to move the cursor much farther, especially on large monitors with lots of real estate. Not to mention that vanishingly few users actually do this.

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

#474

Post by watermelon0 »

happymellon wrote: post #401
watermelon0 wrote: post #233

Earlier quoted context omitted.

Yes, now you can resize from any corner/edge.

Does it show the cursor hint though? If I remember correctly, the confusing part was finding the part of the edge that allowed you to resize as the mouse remained a pointer.

Yes, it shows cursor hint for both edges and corners.

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

#475

Post by tinus_hn »

gardnr wrote: post #269
prewett wrote: post #195

Earlier quoted context omitted.

If you move the mouse up to the top of the screen in fullscreen mode the menu bar will reappear, so things work about like normal (although that certainly wasn't obvious the first time I pressed the green button). The double-click on the title bar is "Zoom" mode, which you can activate with Window >> Zoom. But I agree, it's not obvious, nor is it obvious what "Zoom" means.

This is a bit annoying when an app has its own menu near the top of the screen. The only app I use in full screen is a media player. Every time I try to interact with the in-app hamburger menu, the whole wind shifts and the system window bay animates out. I really don’t like the full screen behaviour in macOS.

Apple would say they don’t like hamburger menus. If the app is designed contrary to the guidelines (which say avoid hamburger menus) and tries to fight the system, unsurprisingly it’s not going to work well with the system.

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

#476

Post by tinus_hn »

davisoneee wrote: post #447
ShadowBanThis01 wrote: post #394

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…

Windows would have exactly the same menus had Apple not had a patent on them when Windows started out.

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

#477

Post by pxc »

Does macOS have any tools for searching (fuzzy filtering) through open windows¹ these days?

I'm recently switching to Mac at work, and the last time I was in it one of the things I missed the most was that feature.

I'm also hoping commenters on this post will be writing about their favorite hacks for emulating tiling WMs on macOS.

--

1: Example, basically exactly the feature I want: https://youtu.be/urqkaWo5geQ

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

#478

Post by pxc »

lloeki wrote: post #198
wrs wrote: post #190

Earlier quoted context omitted.

"Maximize" on MacOS means "go to the largest useful size", not "fill the screen". It's application and context dependent. ("Fill the screen" is a separate mode which the top comment is complaining about, justifiably IMO.)

That's because it's not Maximize, it's Zoom, which uses content hints to resize the window while not wasting space with useless empty space inside the window, thus still allowing one to see other windows. When there's no content size hint it falls back to what Windows and Linux call Maximize, which is more like a windowed fullscreen mode.

This probably reflects my not 'coming from' macOS or idiomatic ways of working in it, but I basically never hit 'maximize' on a window because I want to see more of whatever happens to be in the window. I hit 'maximize' because I want to use an app's internal features (tabs, split panes) to manage multiple app-specific contents/views instead of external window management.

I'm never like

> Ah, just let me resize my browser window so that this image will fit within it!

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

#479

Post by pxc »

lionkor wrote: post #437
s3p wrote: 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.

Linux users: - Meta+Left to snap to the left - Meta+Right to snap to the right - Meta+up to maximize - Meta+down to un-maximize Meta is Win or Alt, depending on your config.

This is the same behavior as on Windows.

On Plasma, Meta+Up snaps to the top, and Meta+Down to the bottom. Meta+PgUp is instead what's used for maximization, and so on.

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

#480

Post by pxc »

Noumenon72 wrote: post #365
bayindirh wrote: post #309

Earlier quoted context omitted.

Also, there's Magnet which does KDE-like window snapping since ages. It's not expensive, works flawlessly and doesn't tax your system in any way.

What I love about my Mac is anything I found that seemed weird to me on first go, there was an app to make it behave exactly the way I would want. I love Magnet and sure hope I will always have it.

I'm hoping things will go better for me this time, but the last time I used a Mac for work (5 or 6 years ago) I found the exact opposite. Many things I wanted couldn't just couldn't be done, even with paid third-party apps. Many more behaviors could be put back in with third party apps, but were either inherently broken or at some point broken by Apple with a new OS release.

From a desktop Linux perspective, Apple is a bit like opposite world. The desktop environment itself is extremely barebones and inflexible, but proprietary app publishers are much more likely to target the platform.

macOS blows what I'm used to out of the water when it comes to the availability of apps (that I'm mostly not interested in, because they're proprietary, single platform, and/or cloud-based), but then the core operating system, from the filesystems to the desktop itself, feels basically extremely incomplete.

Post reply on HN