It has other features too (like saving layouts and keyboard shortcuts), but I don't use them that much.
GNOME made this mistake a long time ago, trying to cargo cult (orig. definition) design their window management tools.
Want a good idea to copy?
Ctrl-C in the terminal should copy text when something is selected, and send interrupt otherwise. In the macOS Terminal, you can rebind Copy from Cmd-C to Ctrl-C; when you do so, this is what happens. I will pledge my unending loyalty to the first terminal emulator on X11/Wayland that can implement this - I've tried over a dozen and none of them do.
(Also, note that you can hold the Option key and click on the green plus in the upper-left corner you will get the standard Windows maximize behavior, which macOS calls "Zoom". Even better, you can go to System Settings > Desktop & Dock > Double click a window's title bar to... and select "Zoom" to make this action even easier.)
No, no you won't. Because 'zoom' is not equivalent to maximization. It means something like 'make this window as big as the current contents it has open for viewing in each dimension, unless that's too big (and then just maximize it in that direction)'.
Additionally it's just window resizing, not a window state. Which means that when you move the window again, it stays huge— so part of it must be offscreen— instead of snapping back to a reasonable unmaximized size.
> So I am curious what you specifically find annoying about treating maximized windows as workspaces.
I'm not GP, but
- there's a big, stupid, slow animation that must play every time you switch between workspaces
- you cannot float windows from other applications over a fullscreen window
Interesting, I tried a few windows that I don't normally "zoom" and you are right. I suppose prior to this I only ever attempted to perform this action on browser/document/messaging/media windows that are able to be fully maximized.
> there's a big, stupid, slow animation that must play every time you switch between workspaces
I wondered how I never noticed this, and it looks like I had Accessibility > Display > Reduce Motion enabled.
> you cannot float windows from other applications over a fullscreen window
Agreed, I found it handy the first time I discovered I could move a floating window over a maximized window in Windows, but I've also noticed that I let my windows become a lot more disorganized when I'm using Windows. I'm not saying they're related, it may be that I just don't have enough Windows experience, but I do find that I end up keeping my workspace a bit tidier on macOS or a tiling WM.
I use Reduce Motion too, but even then there's an animation (it's a cross-fade instead of a wipe) with the same duration and annoyance, although it is less visually distracting and doesn't try to reinforce the worse-than-useless-to-me spatial ordering.
I have to wonder if there's some deep wizardry possible, some hacky function you can call hidden way deep inside Dock.app or Mission Control.app, that will do the workspace switching without any animation.
There's a plist file with animation speeds in it somewhere, and you can reduce the duration of the animations to something extremely low, which is what people with preferences like ours often used to do.
But some time in the last few major releases of macOS, Apple locked that away behind SIP. So to take advantage of it you have to disable some security features (not sure if you have to leave SIP off— you do for some changes but not others), and this may not be possible on a work machine.
I wouldn't do it on a personal machine either (not that you're advocating that).
Yeah, the "full" installation of yabai [0] requires partially disabling SIP permanently, the reasoning for which is laid out very well in [1].
It seems like the "wizardry" I was hoping for would amount to circumventing some basic security design of post-SIP MacOS, so would either be an exploit or else equivalent to turning off the parts of SIP mentioned in [0].
[0] https://github.com/koekeishiya/yabai/wiki/Disabling-System-I... [1] https://github.com/koekeishiya/yabai/issues/798#issuecomment...
that's not the problem (for me at least). i have both workspaces and multiple maximized windows on some of those workspaces. each workspace is dedicated to a task. all windows related to that task, maximized or not, are together on one workspace. pushing maximized windows to their own workspace breaks that. gnome currently behaves as expected, on macos i work around by resizing the window to fill size without using the maximize function. if each fullscreen window had their own space the number of work spaces would double, and they would not be in the order that i want them.
I have a multi-monitor setup and I often find myself using particular monitors for particular applications. I would be annoyed if the operating system decided to start reorganizing them.
and it's not just muscle memory. it takes longer when you have twice as many workspaces in a row. if they would arrange in columns, say workspaces are arranged horizontally, but fullscreen windows are stacked vertically on top or below the workspace they were created from, i could work with that. just not the way macos is doing it, adding them to the end of the horizontal workspace list.
i just noticed that when i disconnect an external monitor, then a seemingly random number of windows that were not on the external monitor, moved to the active workspace. why, gnome, why?!!!
Switching between windows in a unknown workspace arrangement is more effort because you are triggering an action, possibly by taking your hands off the keyboard, grabbing your mouse, moving it somewhere, clicking on something, hunting for the desired item, selecting it. This seems trivial but you are performing the same actually constantly.
- very slow (even with animations turned off - very buggy. Windows resize and move themselves.
Honestly Windows has basically nailed window management (earning its name I guess). Mac is much worse and Gnome is a little worse.
Up until today I'd been using
(global-set-key (kbd "C-c RET")
(lambda () (interactive)
(set-frame-parameter
nil 'fullscreen
(when (not (frame-parameter nil 'fullscreen)) 'maximized))))
I've tentatively switched to it for now, although I noticed some weirdness when I got a message saying that I could run M-x toggle-frame-fullscreen by pressing f11: when I hit globe-f11 the resulting frame/window configuration sometimes ends up being mostly black. When I use M-x toggle-frame-fullscreen, it doesn't have this behavior. [0] https://stackoverflow.com/a/20429390