45 karma · joined October 19, 2013
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.)
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'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.
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.
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.
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.
Not necessarily better for everyone's use case, just solves a different problem.