Hey, Amethyst dev here. Love seeing this on the front page.
I’ve seen a few comments mention it here and there, but I’m swooping in with my semi-regular reminder that you don’t need to disable SIP to use yabai. It’s a great bsp window manager out of the box, with some optional—and admittedly very cool—extra features that require maneuvering around SIP.
(Also, minor apology to Amethyst users because I haven’t managed to get much time to work on it recently.)
This is correct. I can only speak to macOS, but window management in this case is actually built on something entirely distinct from the actual system window manager. It utilizes a framework designed for implementing accessibility driven features, but it just happens to provide mechanisms for moving and tracking windows as a part of that.
At a guess, I would expect kwm to be faster, but probably less far along than Amethyst in terms of features/stability.
It's been a long time since I've actually written any C++, but briefly looking through the code it looks like it's making some of the same assumptions I made that resulted in some strange problems like the dreaded fullscreen bug (https://github.com/ianyh/Amethyst/issues/254). That said, some of those assumptions were made 3 OS X versions ago so things might have improved.
It does, however, look a lot lighter weight than Amethyst is, and it looks like it does a better job at aggressively caching. It also supports binary space partitioning, which Amethyst doesn't support yet (https://github.com/ianyh/Amethyst/issues/255). If I'm reading it correctly, though, that's the only thing it supports.
All in all, it seems like a great project. We could probably learn some things from each other, and I expect both projects would be the better for it.
I haven't had a chance to try reverse engineering the APIs, but on the surface nothing has changed with the accessibility framework, which means we're not going to get much progress towards better window management.
Yeah, there's already an issue to track that (https://github.com/ianyh/Amethyst/issues/129), but in general it seems like people want more flexibility in defining how they want things to tile.
Window spacing is actually in the works for Amethyst. It just has some issues because some windows just don't size exactly. Terminal windows, for example, only size in increments of cursor size, so you're almost always a bit smaller or a bit larger than you want, which makes the spacing in between windows look weird.
Well, Amethyst can float windows so I wouldn't call it a tiling-only WM, but there's a lot of reasons I prefer it over floating window managers.
I'm really lazy and want software to deal with my windows for me. I used floating window managers for a long time and found that I spent a lot of my time arranging windows in the same patterns.
I also found that with floating window managers were just too limited for things I wanted to do on a daily basis. Two come to mind off hand. I want to be able to make a window temporarily bigger, but keeping the other windows on the screen and sized appropriately and I want to be able to easily switch which window is the "primary window." When I'm doing web development without external screens I find it very help to have an editor and a browser window open at the same time. One of them takes up about 80% of the screen and the other takes up about 20% of the screen, but I switch which is which pretty often. Make the editor take up most of the screen, make some changes loosely referencing things in the browser window, make the browser window take up most of the screen and see effects loosely referencing the code in the editor. And sometimes I've also got a Hulu or Netflix window open taking 20% of the width and 50% of the height. The complexity of making that work with a floating window manager is just too much compared to how easy it is for a tiling window manager.
I also just like being able to see everything on my screen at the same time.
Not yet. I've toyed with different ways of doing this, but haven't really decided on one that I really like. Maybe I should just go the road of other window managers that expose a scripting interface. Write a javascript file or something that defines a function that takes a list of windows and some other parameters and returns frames for the windows, binds to commands for modifying layout state, etc.
That is generally correct. I wrote a longer comment about this but SizeUp is about manually managing windows and Amethyst is about letting software manage windows for you. It's generally a matter of personal preference which you prefer.
That's something I want to do. I want basically anything you can do with key commands to be possible via the mouse. Some of that comes out of the box with OS X, but some of it (like dragging to change layout parameters) is a bit trickier.
That is an interesting idea. I'm not actually sure whether or not it's possible. Unfortunately I'm on a plane and my phone won't let me make github issues. I'll add one to look into when I land.
A feature matrix isn't a bad idea (and I opened an issue to track https://github.com/ianyh/Amethyst/issues/267), but it's kind of hard to compare as they are such different pieces of software. Spectacle is manual window management and Amethyst is tiling window management.
Manual window management generally gives you better control and generally less overhead in terms of complexity. So it works well in the case of "I want to be able to move this window to the upper half of the screen", "I want to be able to make this window take up the entire screen", etc. You have to trade simplicity to get flexibility, though. What if I want to be able to move window to the upper right hand quarter of the screen? Or what if I want my screen divided into a grid of 3x4 and I want a window in the [0][1] position? You can accomplish all of those things, but you have to specify how to go about it, thus adding complexity. Slate, for example, puts that complexity upfront in writing a config file. Divvy, for example, puts that complexity at runtime.
Tiling window management gives you a more hands off approach. So things like "I want all of my windows to be laid out in this orientation, but I don't want to move them myself", "I want all of my windows to be visible at any given time", etc. You don't take actions to lay windows out, you just define algorithms for how they should be laid out and let the software sort them out. You have to trade simplicity to get control, though. Defining those algorithms can be complicated if you're not doing something really straightforward, and if you're not doing something straightforward it can sometimes be non-trivial to grok what's actually going on. Or you end up doing a lot of runtime massaging to get things working the way you want.
To each their own, though. I prefer tiling window management, I have coworkers who prefer manual window management. They're just different tools.
This is a woefully confusing decision on my part. There are actually two features: mouse-follows-focus and focus-follows-mouse.
The former just means the cursor moves along with window focus. So if you cycle to the next window clockwise, the cursor moves to the center of that window. Or if you focus a window on another display, the cursor moves to the center of that window. This makes it really convenient to do things like navigating between spaces on multiple displays as the display with the cursor is the one who responds to space switching.
The latter is probably what you're thinking of. You move the cursor and the window underneath it comes into focus. It's kind of experimental and still seems to be fairly buggy, though.
The "impossible" thing is that in OS X there is no distinction between the window that is focused and the window that is the keyboard responder, so the classic idea of focus-follows-mouse doesn't work. I haven't found the distinction personally very meaningful.
It is super buggy for fullscreen apps. Unfortunately, I have this superpower (or curse) of not being able to reproduce bugs. Every time I get near a coworker's computer, whatever they were talking to me about starts working.
There's a long thread on github about this (https://github.com/ianyh/Amethyst/issues/254). I'd love to know more about your set up. I've been trying for weeks to make it work for people, but Apple's APIs for this are kind of crap. And by crap I mean non-existent. I've started using private APIs to do things like figuring out whether or not the current desktop is a fullscreen app.
I'm the Amethyst developer. I'm happy to answer any questions people have. I'm hopping on a cross-country plane flight in about an hour, but I have a layover. I'll try get back to people as soon as I can.
I’ve seen a few comments mention it here and there, but I’m swooping in with my semi-regular reminder that you don’t need to disable SIP to use yabai. It’s a great bsp window manager out of the box, with some optional—and admittedly very cool—extra features that require maneuvering around SIP.
(Also, minor apology to Amethyst users because I haven’t managed to get much time to work on it recently.)