I rarely run across users my age or younger who understand, let alone have, the tendency to keep windows the size of their content, use several at a time, and let them overlap and peek out from behind one another. It is perhaps the Mac way, and I like it, but it definitely works better on a big screen where your windows don’t have to be small to compose a mutual task workflow. Anyway, users can do it however they like.
Apps, though, need to be more flexible than they are. Very often I find that some app that does not serve a primary workflow role will refuse to let its windows get small enough to stick in the corner. Single-window-style apps, whether they’re Electron or just iPad-inspired, often present this kind of problem. Slack, you are not the centerpiece, you are a sideshow.
Having used Macs since 1984, file extensions still annoy me. Why does anyone think it’s good to put metadata in the name of the file? And only this particular piece of metadata (the file format), not anything else, like mod date or permissions.
It’s especially weird when someone says Hungarian notation is awful because they don’t need to see the type of a variable in its name, but then have the opposite attitude when it comes to files…
I agree that the file type would ideally not be embedded into the name of the file. However, it makes sense to me that people would want the file type more prominently displayed than any other file metadata, even if they may not care about the type being literally part of the name.
The reason is that it’s often useful to have files with the same name other than their file type. For example, after saving sheet music as a MuseScore file, I export separate PDF, MIDI, and MP3 files into the same folder with the same file name, so I can later read or listen to the music in specialized apps. In contrast, I don’t know why anyone would want to create two copies of their document with the same name and location but different permissions.
Of course, and it is more prominent — they have different icons, in list view the type column is different, etc. (Which is what it looks like in MacOS if you leave extensions invisible.)
The maddening thing about it is that the pre-OS X approach was so much better. Having both type and creator metadata in the file was useful in addition to being less brittle. It was really nice to be able to open a file by default in the app that created it even if you have 7 different apps on the system that can handle the file type.
I get that file extensions were inevitable because they were used in so many other places, but I’m still upset that they “win” over richer metadata even when said richer data is present.
There’s a short list of other things that I miss from classic Mac OS. But this one is far and away the most aggravating for me.
It’s not a good idea. OS X adopted the practice for the same reason that NeXT did. NeXT supported placing app and framework bundles on NFS shares but NFS didn’t have any features for providing additional metadata. By the time OS X came along, sharing via NFS, SMB, WebDAV, email, floppy disks with FAT16, and so on were common. Arbitrary metadata in the filesystem caused problems because they would work only on HFS+.
This was the same problem BeOS faced. It had a lot of great features but they depended on BFS and abruptly stopped working whenever you needed to use another filesystem.
(edit: Sorry, I misinterpreted your comment. Yes, OS X went backwards on this for reasons. But maybe we can try again.)
Windows has always supported additional metadata in NTFS. Nearly all Linux filesystems support extended file attributes today. It looks from a quick skim of the docs that SMB supports them and there’s an NFSv4 extension for them.
So it seems now the problem isn’t really filesystem support, it’s serialization support. There’s no standard for emailing a file with extended attributes. There’s also no convention for what these attributes would be called. We do have MIME types but they’re kind of half-baked.
Windows has always supported additional metadata in NTFS
True, but when OS X was released it was exposed only via AFP file sharing and some low-level system calls, not via SMB and other things.
Most floppy disks (which were still common) were FAT formatted.
Nearly all Linux filesystems support extended file attributes today.
Today, yes. When OS X was released, not so much. But also not relevant, because OS X never supported ext2. It did (and does) support UFS. As I recall, the UFS code in OS X 10.0 came from FreeBSD 4, FreeBSD 5 was the one that added extended attribute support. OPENSTEP has UFS code from 4BSD, which also lacked this support.
It looks from a quick skim of the docs that SMB supports them and there’s an NFSv4 extension for them.
Both SMB2 and NFS4 postdate OS X by several years. SMB1 and NFS3 (with some things still supporting only NFS2) were the ones available at the time. Most corporate networks used SMB1 from Novell NetWare or NT if they were Windows shops, NFS3 if they were UNIX shops and these did not support metadata in a reliable way.
Even with AFP file sharing from NT, it was easy to have the metadata stripped if you modified the file from a Windows app. A lot of apps would read a file and then do a complete write and rename, which would lose metadata and so would common copy operations. A lot of these problems came up with Classic MacOS, where files were shared with both SMB for Windows and AFP for MacOS, then would be uneditable after a Windows app edited them. You then needed to go and manually edit the metadata for them to work again.
So it seems now the problem isn’t really filesystem support, it’s serialization support. There’s no standard for emailing a file with extended attributes. There’s also no convention for what these attributes would be called. We do have MIME types but they’re kind of half-baked.
That’s less of a problem in some ways. Macs can serialise other streams in metadata, often in a way that admits forwarding by wrapping things in disk images or zip files. The problems come when you need shared access to some medium with metadata-aware and metadata-oblivious operating systems.
Yes, I lived through all those things too…my question is, could we try again now. It’s 2024 and we’re still stuck on file extensions!
In the late 90s there seemed to be some struggle against the featureless binary blob paradigm. I made the Newton OS store that didn’t even have files, left Apple as OpenDoc was trying to introduce a typed-container file format, then went to Microsoft during the post-Cairo era when COM Structured Storage was supposed to get us there, then got sucked into WinFS.
Maybe there’s just too much path dependence and it’s a hopeless cause. At least every end-user OS has some kind of asynchronous store of derived metadata that you can query, which is progress, just not very elegant.
I think so. This was one of the things we wanted to do in Étoilé. Explicitly separating internal storage as a rich object graph and interchange formats. Things that you send in email to users of other systems can be different. Shared filesystems are increasingly rare. Things like Google Docs and MS Office don’t build their collaborative editing on a shared file server.
One last thought — iOS is an interesting (and very popular) alternate world where we got structured data without interoperability. Most iOS applications store their data in siloed SQLite databases and/or proprietary cloud APIs. There is a Files app, but it’s almost entirely used for exchanging serialized data with other systems (cloud filesystems, USB drives, etc.). Very few native iOS applications expose the existence of the filesystem. You have to explicitly “share” data back and forth with Files, you don’t normally go into an app and “open a file”. So in this case we’ve just abandoned the idea of a general data organization capability (folders or metadata or whatever) and made files almost purely a serialization/interop mechanism.
I agree. iOS has some of the things I wanted. Unfortunately, it’s very siloed. Each app is an independent world. This is the opposite of what I wanted to build with Étoilé, where every app could share a common data model and render into a common canvas (which can build the iOS model if you use a component in a canvas by itself, but the converse is not true).
This is closely tied to the economic model. The iOS design is built around the idea of COTS apps as things that you build and sell. A Free Software system should be built around small components that are things you create, modify, and distribute. This is why I get so frustrated when I see FOSS projects building app-store-like things. They are encoding designs that favour proprietary software models in their system design.
another reason is that file formats are not as rigidly defined as date and permissions. a C source file is also a plain text file for example. I think it was a good design decision (not by apple mind you) to leave it to programs to decide whether the data in a file is of a suitable format for a given purpose.
Sure, but that’s more a matter of interpreting the format in some kind of type hierarchy (more probably a heterarchy). The file extension isn’t .c-txt-utf8 or whatever, so it’s already not encoding this aspect.
right, you could come up with a formal taxonomy of file formats and encode it in the filesystem. but I see a lot of drawbacks to that and not much benefit.
Agreed, but you can’t completely leave it up to programs, either — otherwise the system doesn’t even know what program to launch when you try to open a file. The type (at some level, what format is this file) and creator (what’s the default app for this file) pair seem like a good compromise.
There’s a lot of things I like about the macOS paradigm.
The menu bar is great. Did you know you can assign any keyboard shortcut to any menu item at the OS level, even if apps don’t build their own keybind customization setting UI?
It’s as close as you can get to the emacs philosophy of being able to bind any function to any keyboard shortcut. If you’re building a macOS app, put everything imaginable in menu items please!
GUI shortcuts use Cmd by default, almost exclusively. This leaves Ctrl free for escape codes in terminal emulators.
Apps that are self contained folders is so much better than the “installer can run arbitrary code” model. Yes apps can escape this sandbox and write anywhere, but most apps don’t do this meaning most apps uninstall by just deleting a folder. Package managers that install a spider web of unversioned shared libraries or package installers that run arbitrary code on install are way messier.
But things I don’t like:
The “you’re holding it wrong” argument in the article justifying Cmd-Tab switching through apps not windows. Why can’t we have both? Why not one shortcut to cycle windows and one to cycle apps? It doesn’t sully the paradigm to provide that without relying on third parties.
Overlapping, non-full screen windows by default.
I’ve paired with so many people whose approach to window management leaves us looking at 15 lines of code when their setup could easily support 50–100 lines at their current resolution and font preferences. Please let’s get windows maximized by default, and maybe even put tiling back on the table.
Hrmmm. Unfortunately, they appear not to :( In my experimenting just now, it actually cycles between all active windows of all applications; i.e. it cycles through each application’s single foreground window, but not through any non-foreground windows.
Maybe my test was a bit off. I tried with a new message window open in Mail.app, as well as the usual mailbox view. It’d only cycle thru whichever of those two I had last foregrounded; both unminimised. But that new message window might be a special type.
As the article also points out, this is for switching within windows of the current app, not all windows on the system. The claim in the article is that this is actually a good paradigm, and my question is “why can’t you give me a first party keyboard shortcut for cycling through all windows as wel.”
Understood. I don’t really see a use-case for this, but this functionality can be configured in Keyboard Shortcuts in System Settings.app, section “Keyboard”: Uncheck “Move focus to next window” and double-click the shortcut for “Move focus to active or next window” (^F4 by default) and press your desired shortcut.
Cmd is great to leave Ctrl to terminal applications. But Option is not well thought. On Terminal.app, last time I checked, you couldn’t asign one Option as Meta, and leave the other as Option. This prevents the user from typing non-ASCII characters like á. I had to migrate to iTerm. Emacs.app also requires a Mac-specific one-liner on .emacs to deal with this issue.
Terminal.app has a feature that lets you quickly toggle the behavior of the Option key between acting as Alt and its default behavior. It’s one of the only things Terminal.app does that I think is worth emulating
Oh my gosh, so it does! Command-Option-O toggles it, and a nice big indicator appears when you use it telling you which way around it is! That’s way cool.
But Option is not well thought. On Terminal.app, last time I checked, you couldn’t asign one Option as Meta, and leave the other as Option. This prevents the user from typing non-ASCII characters like á.
I wrote a small app for myself for just this purpose back when I was trying out Emacs and didn’t want to switch to iTerm 2 for something so trivial, but also didn’t want to be forced to use the GUI for something so trivial when the console app worked the same for my purposes and I was used to a terminal workflow.
This prevents the user from typing non-ASCII characters like á.
Terminal doesn’t let you switch only one Option over. iTerm2 does, which I was gonna say is “really nice” but actually is just a requirement for a lot of people!
Apps that are self contained folders is so much better than the “installer can run arbitrary code” model. Yes apps can escape this sandbox and write anywhere, but most apps don’t do this meaning most apps uninstall by just deleting a folder. Package managers that install a spider web of unversioned shared libraries or package installers that run arbitrary code on install are way messier.
Not often true IMHO. Apps write to ~/Library/Preferences and other folders all the time. And putting the app folder to the trash of course does not clean any of this.
The “you’re holding it wrong” argument in the article justifying Cmd-Tab switching through apps not windows. Why can’t we have both?
AltTab is a great third party extension that lets you tab through windows instead of applications. If you want you can set the short cut to something besides CMD+Tab. I prefer to override it though.
Hold command while clicking in an unfocused window to send it mouse events without focusing it. Hold option while clicking in it to hide the current app and switch to that window in one go (I use that one a bunch!).
Although I have considered myself a power user of Mac computers for many years, I was unaware of this. I suspect it’s because I’ve always been primarily a keyboard user, starting with my first experience on a ThinkPad laptop, and I generally avoid using a mouse on any computer unless absolutely necessary. While I have a mouse connected, I mostly control my computer with the keyboard, relying on tools like vimari and vim-binding browser extensions. It seems that macOS is more oriented toward users who rely on mouse or touchpad interactions rather than being keyboard-centric. However, this isn’t entirely accurate. As I type this, I recall that cocoa text system includes emacs-like bindings, which many people appreciate. These are present in native Mac apps like TextEdit, Safari, and Finder. Additionally, most menu actions are, or can be, assigned to keyboard shortcuts, and features like “Services” and “App Shortcuts” allow for customized shortcuts for various functions. It’s not that macOS isn’t designed for keyboard-centric users; rather, my personal usage style doesn’t always align with its intended use. Or perhaps I use my Macs in a “wrong” way.
As you’re tabbing through apps in the App Switcher, keep holding down command and hit Q to quit the currently selected app, or hit H to hide it. The App Switcher remains open so you can triage open apps quickly.
That’s a cool tip! The pieces was right in front of me, but I never put them together. This can further be enhanced if you turn on Sticky Keys: Tap Cmdtwice to “stick” it so that you don’t have to hold it anymore. Then, tap Tab. With this, the Cmd-Tab switcher stays on the screen. Now, you can Tab or H or Q your way through it without having to hold the Cmd. When you are done, tap Cmd again. I’m sure this wouldn’t be everyone’s cup of tea though because sticking a modifier key takes getting used to.
When it comes to app/window management, macOS has repeatedly achieved an optimum state, but then abandons the path or ruins the state with further updates.
I have enabled Hover to Click on my system. Combined with the “desktop as files on a desk” metaphor, they make switching between another app/window a breeze because I can just throw my cursor at the exposed portion of a window I want to activate. But, with apps not bothering about the zoom-to-fit-content feature, this metaphor falls apart pretty quickly. Now, you have a humongous file that goes by the name of Firefox or Chrome or JetBrains, which takes up the whole desk. Not that I can blame them – they have a lot of content to fit.
I love the Stage Manager too. The open apps/windows are right there, with large surface area to throw your cursor at. However, it only displays a fixed number of open apps/windows. It takes some mental overhead to realise it, then either cmd-tabbing or docking your way to the wanted app. I thought, “No big deal. I will just minimise the windows I don’t want to see”. But when the Stage Manager is on, a window minimises to the Manager, not the Dock! The best you can do is waste a slot in the Stage Manager to dump all your currently unwanted windows.
Mission Control is an excellent enhancement to the “desktop as files on a desk” metaphor. You zoom out, you see the whole spread, kind of like pushing each stack of documents to their own space on a desk to get a high-level overview. But, when most of the windows are white and similarly sized due to lack of respect for the “zoom-to-fit-content” feature, after a point, sifting through open windows in Mission Control becomes a task. Also, if there are multiple maximised windows (as in those which interpret zoom to cover whole screen space), then they randomly switch places in the spread, eliminating any potential don’t make me think advantage of the spread. I think enlarged app icons besides each window in the spread would have made eyeballing through it easier. I also miss a close button to each window in the Mission Control spread for triaging.
In my opinion it’s a good idea to first understand how the system was designed to be used before decrying it as ill-conceived or making it something it isn’t using third-party window managers, app switchers, and so on.
Certainly it’s a good idea to understand the design intention/philosophy before criticizing. However, nothing in this article explained to me why it seemed like a good idea not to include window resizing shortcuts (as provided by, for example, Rectangle[0]) in the base OS. I’ve only been using it for a couple of months, and I already know it’ll be among the first apps I’ll install on any new machines hereafter.
I think that the implied reasoning is that the intended usage pattern is to only interact with a single app at once (see the “papers on a desk” metaphor). This is is so drastically foreign to my experience as a software developer (usually at least two windows open at once, often 3-5) as to make me wonder if I should finally try using this new-fangled Linux thing people keep talking about on my laptop as well as on servers…
I think that the implied reasoning is that the intended usage pattern is to only interact with a single app at once
I don’t know why I keep seeing people make this supposition. Anyone who attempts to explain macOS’ window management by supposing that it was intended to be used one app at a time knows nothing about Macs, and seems to me to be basing their guess on some caricature of a notion that macOS caters towards non-power-users.
The irony is, the same people before macOS changed the green button to be full-screen by default (i.e. without option held), back when it was called OS X, would have complained or questioned that the zoom button doesn’t maximise the way Windows does, but rather switches between two seemingly arbitrary sizes.
Yep, I will freely admit that I know next-to-nothing about the design intention/philosophy of Macs (although I’d still claim that I know enough about using them to be pretty competent, even if that competence is in spite of my ignorance of the underlying design philosophies).
I’ve now read both an article and a comment that don’t explain the design philosophy motivating the absence of window-tiling functionality. Could you explain that reasoning to me, rather than agreeing with me that I don’t understand it?
I don’t claim to be enough of an authority on the design philosophy of macOS to motivate its absence of window tiling with any eloquence,
as much of it is implicit knowledge from things I devoured years ago as a teenager moving from Windows to Mac OS X Tiger at the time, who immediately felt much more at home on it and got really into online Mac communities (though not as much of an active participant).
However, I can say confidently that macOS wasn’t intended to be used, at least in its standard mode of operation, one app at a time like iOS on a phone. If anything, you could make that argument for Windows much more than macOS, and their respective maximize/zoom behaviours are testament to that.
Yes, Windows has added some tiling functionality and other enhancements, but for a long time, maximising windows was the standard way most people used most apps on Windows. That’s not the case on macOS.
And tiling is not the only way of working with multiple apps at a time. Apart from maybe when only using the browser or watching movies or the like, my impression is that it’s more common standard practice to have overlapping windows on macOS than Windows, and use Exposé or Cmd+Tab or just click windows peeking from underneath the active one to switch between apps and windows.
In fact, I have Terminal windows right now peeking out from behind my browser (and other windows, too), and I instantly notice when the builds I’m constantly running have finished while I do other stuff. Why would I make it take up a whole portion of the screen and relegate my browser window to an edge or half of a screen instead of taking up 70%? (Yeah, yeah, notifications, I don’t care.)
I say that as someone who’s been experimenting with tiling window managers on X, finds them very interesting and can definitely see their appeal, even prefer them in many ways and still use them as my #1 choice on my X-based machines despite not using tilers on macOS (I don’t use Wayland for uninteresting reasons.)
Believe me, I have my gripes with macOS’ window management too (e.g. while I like Cmd+Tab switching between applications not windows, I wish it’d only raise the frontmost window of the selected app instead of all its windows, which would make the stacking work even better).
I just find this particular supposition that macOS is intended to be used one app at a time easily disproven even without much knowledge of macOS design philosophy, and rooted in a caricature of ‘simple’ Mac users (and the irony of one of the simple disproofs being another thing that the same people would probably be confused by and notice, i.e. the difference in window zoom behaviour from Windows).
So to repeat, I’m no expert, but if I were to answer your question with one part of its philosophy, it’d be stack your windows. It’s certainly not about one app at a time.
And tiling is not the only way of working with multiple apps at a time.[…] In fact, I have Terminal windows right now peeking out from behind my browser (and other windows, too), and I instantly notice when the builds I’m constantly running have finished while I do other stuff. Why would I make it take up a whole portion of the screen and relegate my browser window to an edge or half of a screen instead of taking up 70%? (Yeah, yeah, notifications, I don’t care.)
I know I’m opening myself up to an accusation of committing the No True Scotsman fallacy here, but that’s…not using multiple apps at a time. That’s using one app, setting off a long-running job, then “backgrounding” it to work with another app until you can usefully give attention to the first one again. For which case, yep, you absolutely want it to take up the minimal-possible-space to provide you with that the notification (lower-case n - not necessarily through System Notifications) that it’s ready for your attention again. What I’m talking about is when attention and input are switching between two or more apps (IDE/Terminal/Browser, for instance) multiple times in a minute, perhaps once every few seconds. In which setup, I (subjectively!) think it’s reasonable to want each of the active apps’ windows to a) remain static (not resizing repeatedly), and b) all be visible at once (not overlapping, thus not occluding the “next” area of space that’s going to get attention).
Sure, the distinction between the two modes is a matter of degree - in this mode, I, too, am arguably still “backgrounding” each app that I’m not actively interacting with, though for seconds rather than “until I am called back to it in minutes-or-longer” - but nonetheless an important one, I think.
That said, that doesn’t detract from your core argument - that the lack of a tiling manager in MacOS does not imply that the Mac philosophy opposes use of multiple apps at once.
The great thing about stacking window managers is that they don’t force you into one paradigm or the other, you can always align your windows in a tiled manner or not. The downside is having to manage that. Tiled window managers take away the low level task of managing your windows manually, but you lose the control. Classic low level paradigm vs. high level paradigm.
I guess that’s what this crop of modern stacking window managers with easy tiling try to do, combine (the most important, least, middle, or a combination of) 80% of what matters in both worlds (most uses of the term, “best of both worlds” should really be that).
I’d say it a bit stronger, though; it’s not just that it doesn’t oppose the use of humans multitasking w/ several apps, it generally encourages it, even with (manual) tiling. The point about the zoom button’s behaviour still applies to those who, for example, have a browser window on one side — because most web content is tall, not wide — and a terminal on the other.
People have been doing this for a long time, especially on macOS; I only gave a stacking example so that it’s clear you don’t need to be tiling for this to be the case, and that tiling window managers don’t hold a monopoly on multitasking (which is the implication I interpreted from the start of this conversation). What we call tiling window managers simply formalised one particular window arrangement/workflow into a paradigm by automating the process to free up brain cycles.
I’m not even saying the complaint about macOS being slow to add tiling shortcuts is invalid. It’s a fair complaint. It’s just not because macOS discourages multitasking, multitasking has nothing to do with it.
I appreciate your detailed response, thank you! Seems I’ve hit on a particular nerve (no judgement or denigration implied! We all have things that particularly trigger us) on that particular supposition, and I’m sorry for making that mistake.
I mean, it’s like you’re asking why most jeans don’t have cargo pockets. The notable absence!
I wager that most Mac users do not need or want tiling window stuff, let alone keyboard shortcuts (yuck). Three-finger drag is fine. The resize handles are fine (no 1px nonsense). There’s some new tiling stuff under the green button, but I bet most won’t even use it. I don’t even use the built-in tiling on Windows. Is anyone still using Cascade windows ? Window management is just not that hard.
Look, I’m pretty sure I’ve paid for Moom.app years ago—it’s just that tiling’s not that important to most anyone
However, nothing in this article explained to me why it seemed like a good idea not to include window resizing shortcuts (as provided by, for example, Rectangle[0]) in the base OS. I’ve only been using it for a couple of months, and I already know it’ll be among the first apps I’ll install on any new machines hereafter.
FYI it’s finally been added natively in macOS Sequoia just a few weeks ago :)
An annoying thing about it is that when you resize a window to a portion of the screen, it doesn’t use all the available space but leaves a margin of a couple of pixels around it. A small thing but enough to make me keep using Rectangle.
I came from Windows and found macOS to be basically unusable out of the box, so I have a bunch of software to make it work like Windows:
AltTab, also works well with cmd+` switching between the current app’s windows, AltBacktick lets you do that on Windows too
MiddleClick, double 2 finger tap to open/close tabs, I forked it because going plist diving to make it 2 fingers instead of 3 is a pain and the click detection has way too many false positives
Hammerspoon, macOS Autohotkey, I use it to copy win+N/win+up hotkeys from Windows
LinearMouse, lets you configure pointer settings per device, having the same acceleration/sensitivity on your trackpad and mouse makes one of them unusable and this fixes that
BetterTouchTool has replaced AutoHotkey for me, though I wish I’d known about Hammerspoon before because I prefer to write out the config in a text file rather than set it up through a GUI.
Edited DefaultKeyBinding.Dict for familiar text-related keyboard shortcuts like Home/End to go to the beginning/end of a line, Cmd Left/Right to move backward/forward by one word, etc.
This is a pretty cool article but I find that it’s quite user centric. Would be nice to see one diving into some of the more technical tips and tricks that you can do on mac.
This is a pretty cool article but I find that it’s quite user centric.
It’s worth mentioning. A ton of Mac users (TBH, especially the technical ones) don’t really know about the design philosophy of the UI. A lot of it has been changed over time, but it’s still divergent from how Windows, the typical Windows clones of the fd.o world, and the not-so-Windows-clones native to X work. They rarely have an equivalent of i.e. zooming, application focus, proxy icons etc.
For people interested in the historical part, there’s parts of the Mac that have gone away in modern Macs, like spatial Finder, in addition to the remnant ones that have been toned down (like zoom).
A small rant about another useful feature that got ruined: zoom became so useless with Mac OS X that I only ever used it on apps where I knew developers had bothered to implement it correctly (pretty much only the ones from Apple – and only the older ones, at that). Cocoa’s default of making the window go full screen completely ruined the original idea, because almost no third-party developers bothered to make it actually size the window properly; it’s understandable why Apple switched the green button to go to a new, official ‘full screen mode’ in the end, even though that just means I never use the green button at all now.
I think it doesn’t help that it’s hard to know what the ideal content size is for a lot of windows as a developer. For things with fixed sizes like images, it’s obvious, but for i.e. the Music app, what’s a good size for that? It can resize its thumbnails for covers depending on size, so there isn’t necessarily one size.
They funnily also seem to still care about zooming enough to add a modifier for it to SwiftUI in the latest macOS. That does seem to have an “ideal size” option because SwiftUI makes that easier, so funny enough, SwiftUI might make this easier for newer Mac apps.
One of the things I customise pretty much by default on any Mac is to swap the screenshot to clipboard (ctrl-cmd-shift-3/4) and screenshot to file (cmd-shift-3/4) hotkeys
I see tiling mentioned in a few places in the comments, and I want to share that I have hammerspoon keybindings to help arrange windows in a few simple configurations (ex. stretch to fill full monitor size; fill left/right half of monitor; move window to other display). If you’re a mac user wishing there was a free tool that you could set up once to handle your special window handling preferences (using lua, no less) that simply stays invisible and quiet and Just Works for years without changing, maybe try it out. It’s a small thing, I use it 1,000 times a day, and it makes me happy.
I rarely run across users my age or younger who understand, let alone have, the tendency to keep windows the size of their content, use several at a time, and let them overlap and peek out from behind one another. It is perhaps the Mac way, and I like it, but it definitely works better on a big screen where your windows don’t have to be small to compose a mutual task workflow. Anyway, users can do it however they like.
Apps, though, need to be more flexible than they are. Very often I find that some app that does not serve a primary workflow role will refuse to let its windows get small enough to stick in the corner. Single-window-style apps, whether they’re Electron or just iPad-inspired, often present this kind of problem. Slack, you are not the centerpiece, you are a sideshow.
Having used Macs since 1984, file extensions still annoy me. Why does anyone think it’s good to put metadata in the name of the file? And only this particular piece of metadata (the file format), not anything else, like mod date or permissions.
It’s especially weird when someone says Hungarian notation is awful because they don’t need to see the type of a variable in its name, but then have the opposite attitude when it comes to files…
I agree that the file type would ideally not be embedded into the name of the file. However, it makes sense to me that people would want the file type more prominently displayed than any other file metadata, even if they may not care about the type being literally part of the name.
The reason is that it’s often useful to have files with the same name other than their file type. For example, after saving sheet music as a MuseScore file, I export separate PDF, MIDI, and MP3 files into the same folder with the same file name, so I can later read or listen to the music in specialized apps. In contrast, I don’t know why anyone would want to create two copies of their document with the same name and location but different permissions.
Of course, and it is more prominent — they have different icons, in list view the type column is different, etc. (Which is what it looks like in MacOS if you leave extensions invisible.)
The maddening thing about it is that the pre-OS X approach was so much better. Having both type and creator metadata in the file was useful in addition to being less brittle. It was really nice to be able to open a file by default in the app that created it even if you have 7 different apps on the system that can handle the file type.
I get that file extensions were inevitable because they were used in so many other places, but I’m still upset that they “win” over richer metadata even when said richer data is present.
There’s a short list of other things that I miss from classic Mac OS. But this one is far and away the most aggravating for me.
It’s not a good idea. OS X adopted the practice for the same reason that NeXT did. NeXT supported placing app and framework bundles on NFS shares but NFS didn’t have any features for providing additional metadata. By the time OS X came along, sharing via NFS, SMB, WebDAV, email, floppy disks with FAT16, and so on were common. Arbitrary metadata in the filesystem caused problems because they would work only on HFS+.
This was the same problem BeOS faced. It had a lot of great features but they depended on BFS and abruptly stopped working whenever you needed to use another filesystem.
(edit: Sorry, I misinterpreted your comment. Yes, OS X went backwards on this for reasons. But maybe we can try again.)
Windows has always supported additional metadata in NTFS. Nearly all Linux filesystems support extended file attributes today. It looks from a quick skim of the docs that SMB supports them and there’s an NFSv4 extension for them.
So it seems now the problem isn’t really filesystem support, it’s serialization support. There’s no standard for emailing a file with extended attributes. There’s also no convention for what these attributes would be called. We do have MIME types but they’re kind of half-baked.
True, but when OS X was released it was exposed only via AFP file sharing and some low-level system calls, not via SMB and other things.
Most floppy disks (which were still common) were FAT formatted.
Today, yes. When OS X was released, not so much. But also not relevant, because OS X never supported ext2. It did (and does) support UFS. As I recall, the UFS code in OS X 10.0 came from FreeBSD 4, FreeBSD 5 was the one that added extended attribute support. OPENSTEP has UFS code from 4BSD, which also lacked this support.
Both SMB2 and NFS4 postdate OS X by several years. SMB1 and NFS3 (with some things still supporting only NFS2) were the ones available at the time. Most corporate networks used SMB1 from Novell NetWare or NT if they were Windows shops, NFS3 if they were UNIX shops and these did not support metadata in a reliable way.
Even with AFP file sharing from NT, it was easy to have the metadata stripped if you modified the file from a Windows app. A lot of apps would read a file and then do a complete write and rename, which would lose metadata and so would common copy operations. A lot of these problems came up with Classic MacOS, where files were shared with both SMB for Windows and AFP for MacOS, then would be uneditable after a Windows app edited them. You then needed to go and manually edit the metadata for them to work again.
That’s less of a problem in some ways. Macs can serialise other streams in metadata, often in a way that admits forwarding by wrapping things in disk images or zip files. The problems come when you need shared access to some medium with metadata-aware and metadata-oblivious operating systems.
Yes, I lived through all those things too…my question is, could we try again now. It’s 2024 and we’re still stuck on file extensions!
In the late 90s there seemed to be some struggle against the featureless binary blob paradigm. I made the Newton OS store that didn’t even have files, left Apple as OpenDoc was trying to introduce a typed-container file format, then went to Microsoft during the post-Cairo era when COM Structured Storage was supposed to get us there, then got sucked into WinFS.
Maybe there’s just too much path dependence and it’s a hopeless cause. At least every end-user OS has some kind of asynchronous store of derived metadata that you can query, which is progress, just not very elegant.
I think so. This was one of the things we wanted to do in Étoilé. Explicitly separating internal storage as a rich object graph and interchange formats. Things that you send in email to users of other systems can be different. Shared filesystems are increasingly rare. Things like Google Docs and MS Office don’t build their collaborative editing on a shared file server.
One last thought — iOS is an interesting (and very popular) alternate world where we got structured data without interoperability. Most iOS applications store their data in siloed SQLite databases and/or proprietary cloud APIs. There is a Files app, but it’s almost entirely used for exchanging serialized data with other systems (cloud filesystems, USB drives, etc.). Very few native iOS applications expose the existence of the filesystem. You have to explicitly “share” data back and forth with Files, you don’t normally go into an app and “open a file”. So in this case we’ve just abandoned the idea of a general data organization capability (folders or metadata or whatever) and made files almost purely a serialization/interop mechanism.
I agree. iOS has some of the things I wanted. Unfortunately, it’s very siloed. Each app is an independent world. This is the opposite of what I wanted to build with Étoilé, where every app could share a common data model and render into a common canvas (which can build the iOS model if you use a component in a canvas by itself, but the converse is not true).
This is closely tied to the economic model. The iOS design is built around the idea of COTS apps as things that you build and sell. A Free Software system should be built around small components that are things you create, modify, and distribute. This is why I get so frustrated when I see FOSS projects building app-store-like things. They are encoding designs that favour proprietary software models in their system design.
another reason is that file formats are not as rigidly defined as date and permissions. a C source file is also a plain text file for example. I think it was a good design decision (not by apple mind you) to leave it to programs to decide whether the data in a file is of a suitable format for a given purpose.
Sure, but that’s more a matter of interpreting the format in some kind of type hierarchy (more probably a heterarchy). The file extension isn’t
.c-txt-utf8or whatever, so it’s already not encoding this aspect.right, you could come up with a formal taxonomy of file formats and encode it in the filesystem. but I see a lot of drawbacks to that and not much benefit.
Agreed, but you can’t completely leave it up to programs, either — otherwise the system doesn’t even know what program to launch when you try to open a file. The type (at some level, what format is this file) and creator (what’s the default app for this file) pair seem like a good compromise.
Side comment: Apple OSes do have a taxonomy of file formats (Universal Type Identifiers).
IME file(1) has never failed
There’s a lot of things I like about the macOS paradigm.
The menu bar is great. Did you know you can assign any keyboard shortcut to any menu item at the OS level, even if apps don’t build their own keybind customization setting UI?
It’s as close as you can get to the emacs philosophy of being able to bind any function to any keyboard shortcut. If you’re building a macOS app, put everything imaginable in menu items please!
GUI shortcuts use Cmd by default, almost exclusively. This leaves Ctrl free for escape codes in terminal emulators.
Apps that are self contained folders is so much better than the “installer can run arbitrary code” model. Yes apps can escape this sandbox and write anywhere, but most apps don’t do this meaning most apps uninstall by just deleting a folder. Package managers that install a spider web of unversioned shared libraries or package installers that run arbitrary code on install are way messier.
But things I don’t like:
The “you’re holding it wrong” argument in the article justifying Cmd-Tab switching through apps not windows. Why can’t we have both? Why not one shortcut to cycle windows and one to cycle apps? It doesn’t sully the paradigm to provide that without relying on third parties.
Overlapping, non-full screen windows by default.
I’ve paired with so many people whose approach to window management leaves us looking at 15 lines of code when their setup could easily support 50–100 lines at their current resolution and font preferences. Please let’s get windows maximized by default, and maybe even put tiling back on the table.
Let me introduce you to the keyboard shortcut to cycle through windows:
Cmd-`I think they may want one to cycle windows from all apps, and then one for apps.
⌃F4 and Shift⌃F4 cycle between all windows (of all applications) in the current desktop, but it’s not very ergonomic.
Hrmmm. Unfortunately, they appear not to :( In my experimenting just now, it actually cycles between all active windows of all applications; i.e. it cycles through each application’s single foreground window, but not through any non-foreground windows.
It works for all non-minimized windows for me. And see my other comment on how to change the shortcut to something more ergonomic.
Maybe my test was a bit off. I tried with a new message window open in Mail.app, as well as the usual mailbox view. It’d only cycle thru whichever of those two I had last foregrounded; both unminimised. But that new message window might be a special type.
As the article also points out, this is for switching within windows of the current app, not all windows on the system. The claim in the article is that this is actually a good paradigm, and my question is “why can’t you give me a first party keyboard shortcut for cycling through all windows as wel.”
Understood. I don’t really see a use-case for this, but this functionality can be configured in Keyboard Shortcuts in System Settings.app, section “Keyboard”: Uncheck “Move focus to next window” and double-click the shortcut for “Move focus to active or next window” (^F4 by default) and press your desired shortcut.
Cmd is great to leave Ctrl to terminal applications. But Option is not well thought. On Terminal.app, last time I checked, you couldn’t asign one Option as Meta, and leave the other as Option. This prevents the user from typing non-ASCII characters like á. I had to migrate to iTerm. Emacs.app also requires a Mac-specific one-liner on .emacs to deal with this issue.
Terminal.app has a feature that lets you quickly toggle the behavior of the Option key between acting as Alt and its default behavior. It’s one of the only things Terminal.app does that I think is worth emulating
:O
Oh my gosh, so it does! Command-Option-O toggles it, and a nice big indicator appears when you use it telling you which way around it is! That’s way cool.
I wrote a small app for myself for just this purpose back when I was trying out Emacs and didn’t want to switch to iTerm 2 for something so trivial, but also didn’t want to be forced to use the GUI for something so trivial when the console app worked the same for my purposes and I was used to a terminal workflow.
Here you go!
You can set this on specific profiles. On Terminal.app settings > “Profiles” > select your profile > “Keyboard” > “Use Option as Meta key”
But then, per @nextos:
Terminal doesn’t let you switch only one Option over. iTerm2 does, which I was gonna say is “really nice” but actually is just a requirement for a lot of people!
Oh, that makes sense! I didn’t understand at first
Not often true IMHO. Apps write to ~/Library/Preferences and other folders all the time. And putting the app folder to the trash of course does not clean any of this.
Settings are something I do want to persist except if I’m getting rid of them explicitly.
AltTab is a great third party extension that lets you tab through windows instead of applications. If you want you can set the short cut to something besides CMD+Tab. I prefer to override it though.
https://alt-tab-macos.netlify.app/
Although I have considered myself a power user of Mac computers for many years, I was unaware of this. I suspect it’s because I’ve always been primarily a keyboard user, starting with my first experience on a ThinkPad laptop, and I generally avoid using a mouse on any computer unless absolutely necessary. While I have a mouse connected, I mostly control my computer with the keyboard, relying on tools like vimari and vim-binding browser extensions. It seems that macOS is more oriented toward users who rely on mouse or touchpad interactions rather than being keyboard-centric. However, this isn’t entirely accurate. As I type this, I recall that cocoa text system includes emacs-like bindings, which many people appreciate. These are present in native Mac apps like TextEdit, Safari, and Finder. Additionally, most menu actions are, or can be, assigned to keyboard shortcuts, and features like “Services” and “App Shortcuts” allow for customized shortcuts for various functions. It’s not that macOS isn’t designed for keyboard-centric users; rather, my personal usage style doesn’t always align with its intended use. Or perhaps I use my Macs in a “wrong” way.
*by vimari, I mean Vimac, now known as Homerow. There is also a free alternative called Shortcat.
That’s a cool tip! The pieces was right in front of me, but I never put them together. This can further be enhanced if you turn on Sticky Keys: Tap
Cmdtwice to “stick” it so that you don’t have to hold it anymore. Then, tapTab. With this, the Cmd-Tab switcher stays on the screen. Now, you canTaborHorQyour way through it without having to hold the Cmd. When you are done, tapCmdagain. I’m sure this wouldn’t be everyone’s cup of tea though because sticking a modifier key takes getting used to.When it comes to app/window management, macOS has repeatedly achieved an optimum state, but then abandons the path or ruins the state with further updates.
I have enabled Hover to Click on my system. Combined with the “desktop as files on a desk” metaphor, they make switching between another app/window a breeze because I can just throw my cursor at the exposed portion of a window I want to activate. But, with apps not bothering about the zoom-to-fit-content feature, this metaphor falls apart pretty quickly. Now, you have a humongous file that goes by the name of Firefox or Chrome or JetBrains, which takes up the whole desk. Not that I can blame them – they have a lot of content to fit.
I love the Stage Manager too. The open apps/windows are right there, with large surface area to throw your cursor at. However, it only displays a fixed number of open apps/windows. It takes some mental overhead to realise it, then either cmd-tabbing or docking your way to the wanted app. I thought, “No big deal. I will just minimise the windows I don’t want to see”. But when the Stage Manager is on, a window minimises to the Manager, not the Dock! The best you can do is waste a slot in the Stage Manager to dump all your currently unwanted windows.
Mission Control is an excellent enhancement to the “desktop as files on a desk” metaphor. You zoom out, you see the whole spread, kind of like pushing each stack of documents to their own space on a desk to get a high-level overview. But, when most of the windows are white and similarly sized due to lack of respect for the “zoom-to-fit-content” feature, after a point, sifting through open windows in Mission Control becomes a task. Also, if there are multiple maximised windows (as in those which interpret zoom to cover whole screen space), then they randomly switch places in the spread, eliminating any potential don’t make me think advantage of the spread. I think enlarged app icons besides each window in the spread would have made eyeballing through it easier. I also miss a close button to each window in the Mission Control spread for triaging.
Certainly it’s a good idea to understand the design intention/philosophy before criticizing. However, nothing in this article explained to me why it seemed like a good idea not to include window resizing shortcuts (as provided by, for example, Rectangle[0]) in the base OS. I’ve only been using it for a couple of months, and I already know it’ll be among the first apps I’ll install on any new machines hereafter.
I think that the implied reasoning is that the intended usage pattern is to only interact with a single app at once (see the “papers on a desk” metaphor). This is is so drastically foreign to my experience as a software developer (usually at least two windows open at once, often 3-5) as to make me wonder if I should finally try using this new-fangled Linux thing people keep talking about on my laptop as well as on servers…
[0] https://rectangleapp.com/
I don’t know why I keep seeing people make this supposition. Anyone who attempts to explain macOS’ window management by supposing that it was intended to be used one app at a time knows nothing about Macs, and seems to me to be basing their guess on some caricature of a notion that macOS caters towards non-power-users.
The irony is, the same people before macOS changed the green button to be full-screen by default (i.e. without option held), back when it was called OS X, would have complained or questioned that the zoom button doesn’t maximise the way Windows does, but rather switches between two seemingly arbitrary sizes.
Yep, I will freely admit that I know next-to-nothing about the design intention/philosophy of Macs (although I’d still claim that I know enough about using them to be pretty competent, even if that competence is in spite of my ignorance of the underlying design philosophies).
I’ve now read both an article and a comment that don’t explain the design philosophy motivating the absence of window-tiling functionality. Could you explain that reasoning to me, rather than agreeing with me that I don’t understand it?
I don’t claim to be enough of an authority on the design philosophy of macOS to motivate its absence of window tiling with any eloquence,
as much of it is implicit knowledge from things I devoured years ago as a teenager moving from Windows to Mac OS X Tiger at the time, who immediately felt much more at home on it and got really into online Mac communities (though not as much of an active participant).
However, I can say confidently that macOS wasn’t intended to be used, at least in its standard mode of operation, one app at a time like iOS on a phone. If anything, you could make that argument for Windows much more than macOS, and their respective maximize/zoom behaviours are testament to that.
Yes, Windows has added some tiling functionality and other enhancements, but for a long time, maximising windows was the standard way most people used most apps on Windows. That’s not the case on macOS.
And tiling is not the only way of working with multiple apps at a time. Apart from maybe when only using the browser or watching movies or the like, my impression is that it’s more common standard practice to have overlapping windows on macOS than Windows, and use Exposé or Cmd+Tab or just click windows peeking from underneath the active one to switch between apps and windows.
In fact, I have Terminal windows right now peeking out from behind my browser (and other windows, too), and I instantly notice when the builds I’m constantly running have finished while I do other stuff. Why would I make it take up a whole portion of the screen and relegate my browser window to an edge or half of a screen instead of taking up 70%? (Yeah, yeah, notifications, I don’t care.)
I say that as someone who’s been experimenting with tiling window managers on X, finds them very interesting and can definitely see their appeal, even prefer them in many ways and still use them as my #1 choice on my X-based machines despite not using tilers on macOS (I don’t use Wayland for uninteresting reasons.)
Believe me, I have my gripes with macOS’ window management too (e.g. while I like Cmd+Tab switching between applications not windows, I wish it’d only raise the frontmost window of the selected app instead of all its windows, which would make the stacking work even better).
I just find this particular supposition that macOS is intended to be used one app at a time easily disproven even without much knowledge of macOS design philosophy, and rooted in a caricature of ‘simple’ Mac users (and the irony of one of the simple disproofs being another thing that the same people would probably be confused by and notice, i.e. the difference in window zoom behaviour from Windows).
So to repeat, I’m no expert, but if I were to answer your question with one part of its philosophy, it’d be stack your windows. It’s certainly not about one app at a time.
I know I’m opening myself up to an accusation of committing the No True Scotsman fallacy here, but that’s…not using multiple apps at a time. That’s using one app, setting off a long-running job, then “backgrounding” it to work with another app until you can usefully give attention to the first one again. For which case, yep, you absolutely want it to take up the minimal-possible-space to provide you with that the notification (lower-case n - not necessarily through System Notifications) that it’s ready for your attention again. What I’m talking about is when attention and input are switching between two or more apps (IDE/Terminal/Browser, for instance) multiple times in a minute, perhaps once every few seconds. In which setup, I (subjectively!) think it’s reasonable to want each of the active apps’ windows to a) remain static (not resizing repeatedly), and b) all be visible at once (not overlapping, thus not occluding the “next” area of space that’s going to get attention).
Sure, the distinction between the two modes is a matter of degree - in this mode, I, too, am arguably still “backgrounding” each app that I’m not actively interacting with, though for seconds rather than “until I am called back to it in minutes-or-longer” - but nonetheless an important one, I think.
That said, that doesn’t detract from your core argument - that the lack of a tiling manager in MacOS does not imply that the Mac philosophy opposes use of multiple apps at once.
The great thing about stacking window managers is that they don’t force you into one paradigm or the other, you can always align your windows in a tiled manner or not. The downside is having to manage that. Tiled window managers take away the low level task of managing your windows manually, but you lose the control. Classic low level paradigm vs. high level paradigm.
I guess that’s what this crop of modern stacking window managers with easy tiling try to do, combine (the most important, least, middle, or a combination of) 80% of what matters in both worlds (most uses of the term, “best of both worlds” should really be that).
I’d say it a bit stronger, though; it’s not just that it doesn’t oppose the use of humans multitasking w/ several apps, it generally encourages it, even with (manual) tiling. The point about the zoom button’s behaviour still applies to those who, for example, have a browser window on one side — because most web content is tall, not wide — and a terminal on the other.
People have been doing this for a long time, especially on macOS; I only gave a stacking example so that it’s clear you don’t need to be tiling for this to be the case, and that tiling window managers don’t hold a monopoly on multitasking (which is the implication I interpreted from the start of this conversation). What we call tiling window managers simply formalised one particular window arrangement/workflow into a paradigm by automating the process to free up brain cycles.
I’m not even saying the complaint about macOS being slow to add tiling shortcuts is invalid. It’s a fair complaint. It’s just not because macOS discourages multitasking, multitasking has nothing to do with it.
Fair!
I appreciate your detailed response, thank you! Seems I’ve hit on a particular nerve (no judgement or denigration implied! We all have things that particularly trigger us) on that particular supposition, and I’m sorry for making that mistake.
I mean, it’s like you’re asking why most jeans don’t have cargo pockets. The notable absence!
I wager that most Mac users do not need or want tiling window stuff, let alone keyboard shortcuts (yuck). Three-finger drag is fine. The resize handles are fine (no 1px nonsense). There’s some new tiling stuff under the green button, but I bet most won’t even use it. I don’t even use the built-in tiling on Windows. Is anyone still using Cascade windows ? Window management is just not that hard.
Look, I’m pretty sure I’ve paid for Moom.app years ago—it’s just that tiling’s not that important to most anyone
FYI it’s finally been added natively in macOS Sequoia just a few weeks ago :)
https://support.apple.com/fr-fr/guide/mac-help/mchlef287e5d/mac
It’s less powerful than Rectangle, but does everything I used Rectangle for!
An annoying thing about it is that when you resize a window to a portion of the screen, it doesn’t use all the available space but leaves a margin of a couple of pixels around it. A small thing but enough to make me keep using Rectangle.
I also disliked that, but luckily it can be configured in the Desktop & Dock settings.
Thanks, that’s much better!
I just saw that announcement today, and thought of this discussion!
I came from Windows and found macOS to be basically unusable out of the box, so I have a bunch of software to make it work like Windows:
That’s a good list, I’d also add Easy Move+Resize to it:
https://github.com/dmarcotte/easy-move-resize
although it stopped working for me in Sequoia, haven’t got the time to figure out what’s wrong yet.
I also come from Windows (these days I use Linux Mint, which is Windows-like). AltTab is great. Here are some others I’ve found useful:
This page also contains some useful Mac UX tips:
https://saurabhs.org/macos-tips
This is a pretty cool article but I find that it’s quite user centric. Would be nice to see one diving into some of the more technical tips and tricks that you can do on mac.
It’s worth mentioning. A ton of Mac users (TBH, especially the technical ones) don’t really know about the design philosophy of the UI. A lot of it has been changed over time, but it’s still divergent from how Windows, the typical Windows clones of the fd.o world, and the not-so-Windows-clones native to X work. They rarely have an equivalent of i.e. zooming, application focus, proxy icons etc.
For people interested in the historical part, there’s parts of the Mac that have gone away in modern Macs, like spatial Finder, in addition to the remnant ones that have been toned down (like zoom).
A small rant about another useful feature that got ruined: zoom became so useless with Mac OS X that I only ever used it on apps where I knew developers had bothered to implement it correctly (pretty much only the ones from Apple – and only the older ones, at that). Cocoa’s default of making the window go full screen completely ruined the original idea, because almost no third-party developers bothered to make it actually size the window properly; it’s understandable why Apple switched the green button to go to a new, official ‘full screen mode’ in the end, even though that just means I never use the green button at all now.
I think it doesn’t help that it’s hard to know what the ideal content size is for a lot of windows as a developer. For things with fixed sizes like images, it’s obvious, but for i.e. the Music app, what’s a good size for that? It can resize its thumbnails for covers depending on size, so there isn’t necessarily one size.
They funnily also seem to still care about zooming enough to add a modifier for it to SwiftUI in the latest macOS. That does seem to have an “ideal size” option because SwiftUI makes that easier, so funny enough, SwiftUI might make this easier for newer Mac apps.
[Comment removed by author]
One of the things I customise pretty much by default on any Mac is to swap the screenshot to clipboard (ctrl-cmd-shift-3/4) and screenshot to file (cmd-shift-3/4) hotkeys
I see tiling mentioned in a few places in the comments, and I want to share that I have hammerspoon keybindings to help arrange windows in a few simple configurations (ex. stretch to fill full monitor size; fill left/right half of monitor; move window to other display). If you’re a mac user wishing there was a free tool that you could set up once to handle your special window handling preferences (using lua, no less) that simply stays invisible and quiet and Just Works for years without changing, maybe try it out. It’s a small thing, I use it 1,000 times a day, and it makes me happy.
These are now built-ins: https://support.apple.com/guide/mac-help/mac-window-tiling-icons-keyboard-shortcuts-mchl9674d0b0/15.0/mac/15.0
Ah, TIL, thank you for the comment and link. Good to know that some basic handling is available out of the box.