The window api makes me think one could pretty easily create an i3 like window manager. But my past experience with OSX window managers like amethyst has been subpar. Often the sizing/positioning is taken more as a “suggestion” by the window than a command. I also found eventually windows would get into a bad state. Has window management on OSX improved in the past couple years? On Linux with X11, window managers truly have control and thus provide a more reliable experience.
I have had a pretty stable setup using yabai[0] for my wm and skhd[1] for my hotkey daemon. Both are by the same dev and I have nothing but good things to say about them. Occasionally windows will get in a wonky state, but I have a hot key to reset them. It is usually stable for a week+
+1 for yabai with skhd! I can't imagine working on macos without it and I really can't stress this enough. Hotkeys with skhd is game changer for productivity and nothing compares to yabai for a tiling window manager on macos (though you don't have to use the tiling if that's not your thing).
I've been using yabai as well! I was wondering if it was possible to replicate iTerm2's dedicated hotkey window [1] for other applications (primarily firefox) using yabai/skhd?
I do not know the answer to your question but the way I solve that problem in osx is using quicksilver and triggers. You can give each app or really any quicksilver command a hotkey to switch to it directly or start it and switch if it's not running. I couldn't live without it. I have hotkeys for all my commonly used apps and generally never launch or switch apps any other way. I also have hotkeys for manual tiling to the corners, sides, center, and full screen so I don't need to use the gui for that. The fact that this isn't doable out of the box makes me question if either Apple or Microsoft has ever considered hiring a single ux expert.
On Linux I use jumpapp for the same functionality.
I've been using yabai and skhd for about a week, I was wondering what you are using for your menu bar? I'm not really sure about a suitable replacement for something like i3bar coming from Linux.
It really doesn't work that well especially on small screens. Spotify for example has a minimum size and will be unusable when the tile is smaller than that because half the window isn't visible. Focus-follows-mouse is also broken when using multiple screens and workspaces.
I've been thinking of using these. What I want also is to "save and restore" or just "force" some windows to specific monotors and sizes. Is that possible with yabai?
Not GP, but that's better than my Mac as a whole. Weird OS issues with the trackpad, login, or fan/cpu/ram usage despite nothing big running necessitate a restart at least once a week.
I would generally agree, except in this case that makes it one of the more stable pieces of software I am running on my mac. When it happens I have a single hotkey mapped to restart the service which recollects all my windows and usually fixes anything that was going wrong in ~3-4 seconds.
I love i3. I wish I could get something like it for the Mac. I love it so much I might ditch my Mac for a Linux laptop. Regarding Phoenix I use magnet on the Mac which gets pretty much this. Though this is probably much more customizable. Link: https://apps.apple.com/us/app/magnet/id441258766?mt=12
I have run with SIP disabled pretty much since it was introduced. Nothing happened. Unless you are a three-letter-agency target or a person clicking on random files, you’ll be fine.
I'm using Hammerspoon on MaOS to give me a semi-tileable windows interface. Here is my config:
local hyper = {"ctrl", "alt", "cmd"}
hs.loadSpoon("MiroWindowsManager")
hs.window.animationDuration = 0.3
spoon.MiroWindowsManager:bindHotkeys({
up = {hyper, "up"},
right = {hyper, "right"},
down = {hyper, "down"},
left = {hyper, "left"},
fullscreen = {hyper, "f"}
})
-- https://github.com/miromannino/miro-windows-manager
This allows me to place any MacOS window in either a horizontal or vertical third, or a quadrant, or a half, perfectly divided in such a way that I can maximise use of my screen while running multiple apps. My most common work environment is to have a terminal on one half of the screen, docs on the other - or two terms on top of each other on one side, docs on the other.
This is so useful for me that I yearn to make the same hotkeys work on my Linux machine, but I haven't worked out what window manager I want to use to do it .. probably Awesome of course, but I'd love to be able to use the same Hammerspoon scripts (Lua) somehow ..
I've been using Hammerspoon for years, and have been incredibly happy with it. It is still actively maintained, has a large userbase, and has a lot of pre-built solutions for things. Importantly, it's not just for window management. You can do a lot of powerful things with it.
> Out of curiosity, what kind of things do people script in a window manager?
KWin is scriptable, and I use it to change window shading behavior and to do some tiling. At one point I had it send SIGSTOP to processes that I minimized, and SIGCONT when they were raised, to save battery life.
Pretty happy with spectacle overall. One thing I sorely miss from i3 however is the ability to switch focus to panes/windows/apps with the keyboard. Even something as next/prev window seems impossible on Mac (or I couldn’t work out a solution). I think you can cycle through apps(?), but not windows/panes in a logical order as far as I’m aware.
I mapped it to cmd-shift-right so it does go to the next window. But there's no way that I could find to map going to the previous window... So for example I might have two windows tiled side by side. I want to go cmd-shift-right to focus on the right one, and cmd-shift-left to focus on the left...
Thanks. I'm going to try Hammerspoon (and maybe HyperSwitch).
From other comments, it seems like yabai can also handle it, but it seems like a very "hard-core" way, including disabling some Mac security features, and I'm not sure I feel comfortable going that far yet :)
It's not exactly what you want, but have you tried binding "Move focus to next window" to alt+tab? Then you can use alt-tab-shift to cycle focus backwards, at least something. (I always forget where that setting is, it's in Keyboard->Shortcuts->Keyboard).
> If you have two windows the order shouldn't matter?
No. But I don't think it's too much to ask to cycle through more than two, now, is it? :)
> Also, Cmd+` goes to the next window, Cmd+Shift+` goes to the previous window, your mappings having a shift in them might be the issue.
I'm not sure I understand how having a shift in my mapping affects this, but cmd-shift-` isn't ergonomic at all. To me the arrows are far more logical way to go in a certain direction. Why can I map next window to any key, but there's no way to map another key to the previous window? I find it very strange.
For the sake of comparison, i3 makes all those things trivial.
I got your link from an older post about Phoenix on HN. It’s really well done (as some replies to you on the older thread said)!
Have you, by any chance, tried Hammerspoon (hammerspoon.org)? That seems to be tool with a broader feature set compared to Phoenix. I was looking for some kind of well analyzed and written comparison.
I have not tried Hammerspoon but I've skimmed through their docs, I'd say ultimately it boils down to: do you want to write JS or Lua? And do you need any of the Hammerspoon-specific features? I personally don't know any Lua and actually quite like writing JS, I don't think I need any of extra features HS provides, and with Phoenix you can still run a shell script and still achieve many things HS provides explicitly.
I grew up in the 80s during the era of MacroMaker and QuickKeys, when you could just hit the record button and make macros to play back sequences of mouse and keyboard events. It was especially useful in programs like Photoshop before they added their own macro systems. I'm having trouble finding links about it:
The frontier was to eventually make everything scriptable and deterministic by getting more apps to have hooks that could be controlled directly (so like a specific command to click the close box of a window for example, rather than sending a click event right and down from the top left corner).
Anyway, this whole concept of how to use computers seems to be all but dead today and I can't help but feel that something of tremendous value has been lost. Please, if you ever write macro tools like Phoenix, add a record feature.
It does seem like we've realized that GUIs are not really the most automation-friendly way to interact with programs. But there are a lot of nice macro tools out there still.
For Windows, there is a macro scripting language Autohotkey [0], which has powerful recording GUIs built on it [1]. Although it doesn't support application-specific hooks that I'm aware of, it does allow introspection into the rendered GUI of the application, so you can "click a button" instead of "click a pixel".
OS X has Keyboard Maestro [2], which I've heard is good.
Also, many keyboards have macro recording built in. My Ducky keyboard can record and save macros with no custom software/driver needed. (the macros can even include mouse clicks, but that's a little janky.)
As a final note, I think the place I've seen macro recording still used the most is in gaming. In most other areas of computing, it's seen as preferable to make a special-purpose utility to solve a problem instead of building layers of automation on top of a more general-purpose tool.
(btw, this is just based on my personal experience -- I love automation so I've never been far from the macro-space. I'm not trying to argue against your point.)
> It does seem like we've realized that GUIs are not really the most automation-friendly way to interact with programs. But there are a lot of nice macro tools out there still.
Yeah, in general the opinion seems to be "you want to manually do stuff, use a GUI. If you want automation, use the API of either a server-side backend or CLI tool", but there is a huge segment of users that are between that. Imagine power users that don't know how to program. For them to be able to quickly record > playback some common thing they do, would save a lot of time and be valuable
For automation I like to have at least something like AutoHotKey or Sikuli, because there will always come up little temporary tasks that are time limited that you don't have the time to learn the apis needed to automate it before the whole task is supposed to be done, but the task itself is still so tedious and time consuming that it might run over time if not automated.
Focus-follows-mouse, even sloppy, is problematic on macOS due to the menu bar. Moving the mouse up to the menu bar means covering space which can belong to a different window, which would change the meaning of the menu item when you got there.
"Focus-follows-mouse, even sloppy, is problematic on macOS due to the menu bar. Moving the mouse up to the menu bar means covering space which can belong to a different window, which would change the meaning of the menu item when you got there."
This is true, but easily surmountable.
Mondomouse, which is the last bona-fide focus-follows-mouse add-on that existed for OSX (circa snow leopard) had a switch timer that was user-definable.
So you could set the switch timer to .5 seconds or 1 second or something which would allow you to run the mouse across other windows without changing focus. That solved the menu bar problem that you are, correctly, pointing out.
I think it's also worth mentioning that if you're at the point where you're demanding FFM, you're probably already doing everything with hotkeys anyway so it's not like you're running up to the menu bar often ...
Focus-follows-mouse is sorely needed, at least as an option, in OSX.
I used to achieve FFM, circa snow-leopard, with the excellent "mondomouse" from AtomicBird, but it is no longer maintained and will not work with modern OSX versions.
Looking ahead, it appears that there is some new capability buried deep inside the accessibility section of Preferences that actually enables FFM, but I do not have a new enough (Mojave ?) version of OSX to verify this ...
EDIT: I think it is actually High Sierra that this new accessibility feature appeared in, but again, not sure ...
Highlight-to-copy works inside the Terminal app, it just doesn't use the public pasteboard. You Shift-Command-V to paste. Dunno whether MMB would work too, or could be configured to do it.
yabai has a feature that allows for focus following mouse. It's a little wonky with the menu bar, but it works pretty well and replicates the X11 feel pretty well.
Based on other links listed [1] in this comment right here and a little bit of reading up, it seems like Phoenix focuses on window and app management whereas Hammerspoon supports many more types of events and hooks to develop actions/plugins on. Does anyone have a better comparison of these two?
Interesting, I need to check this out. I currently use Amethyst[1], and while I like it, it’s definitely got some bugs/performance issues. I’ve also heard people use chunkwm with good results, but haven’t tried it myself.
I have been using Spectacle for ages (with a custom javascript config, another post...).
The problem is, Spectacle uses a 32bit API that is scheduled to go away and I am afraid that at some point (or 10.15 already?) it will stop working.
Spectacle is another alternative on macOS [1]. There's also Amethyst. I'm not sure which one's best. It is a matter of getting used to the default keybinds IMO.
With Spectacle, the default keybinds are using Alt and Cmd as super key. I like that one; I rather keep Caps Lock as Esc (else I'd use it as Ctrl).
As for i3, there's a backwards compatible Wayland successor called Sway [2].
You can do a lot of this stuff without a full app, you just need a way to trigger an AppleScript with a keyboard shortcut. This is my framework for this approach. https://github.com/robenkleene/windowpane
(I have a similar Javascript configuration for Spectacle, I can post it if there is interest. I believe the javascript is easily portable to other scriptable window managers.)
My rationale for developing lrtile is the following:
I like having window corners on a grid because it helps locating information.
However, in many tiled WMs, resizing one window causes resizing of nearby ones (very distracting) _and_ windows generally do not overlap (a severe limitation especially on small screen). Finally, shortcuts to place windows on half or a quarter of the screen are often built-in (in chrome, windows, spectacle default...) but very few WMs have larger, configurable grids suitable for large monitors (I use a 40" 4K screen).
lrtile addresses the above problems as follows:
- the grid is configurable;
- movement/resize only affect the current window, allowing overlap if user wants;
- commands are arrows + 1/2 modifiers, and try to be intuitive
- screen borders act as hard stops, also making behavior more intuitive.
In detail, I typically use a 6x6 grid on small screens (so I can have halves or thirds) and 12x10 or even bigger on large screens. Each window side must be at least two units, and resize extends or reduces one dimension at a time and by one unit.
My typical workflow is to make windows visible with a comfortable size and no overlap, and occasionally expand the window I care about (e.g. make the browser wider when a page does not render well; or expand the editor window vertically when I want to see a larger chunk of code), reverting back when done. The fact that move and resize commands are very similar to other cursor movements makes the operation very quick.
Is there something similar for Linux? I was just reviewing Guile and thought it would be something like that, but it isn't, and is Lisp. I would love something similar on Linux.
I don't think anyone will be confused... seeing as it's also the name of about a billion other things (Pre-Firefox, I still remember you!). I feel like "Pheonix" is the second most common project name behind "Matrix".
And on a less nit-pick-y note if the author is reading this - the project looks really fun and is certainly going to take up a chunk of my weekend!
[0]https://github.com/koekeishiya/yabai [1]https://github.com/koekeishiya/skhd
[1] https://www.iterm2.com/documentation-hotkey.html
On Linux I use jumpapp for the same functionality.
[0]https://github.com/felixhageloh/uebersicht
I haven't had any issue with it coming from i3bar/polybar, but then I don't really do anything specific with it, just time and battery.
I had 240 days of uptime on my G5 Mac Pro at one point.
I doubt we'll ever see that kind of stability in macOS again, and it makes me sad.
I sorely miss it when I am using windows or MacOS.
https://github.com/koekeishiya/yabai
I have used Spectacle [3] for years and recently switched to Rectangle [4].
These two are quite simple in comparison but I barely use all their features.
I have seen people using HammerSpoon [5] as well for these type of things.
Out of curiosity, what kind of things do people script in a window manager?
[1] https://github.com/kasper/phoenix/blob/bfcb684/docs/API.md
[2] https://news.ycombinator.com/item?id=16787836
[3] https://www.spectacleapp.com/
[4] https://rectangleapp.com/
[5] https://www.hammerspoon.org/
This is so useful for me that I yearn to make the same hotkeys work on my Linux machine, but I haven't worked out what window manager I want to use to do it .. probably Awesome of course, but I'd love to be able to use the same Hammerspoon scripts (Lua) somehow ..
KWin is scriptable, and I use it to change window shading behavior and to do some tiling. At one point I had it send SIGSTOP to processes that I minimized, and SIGCONT when they were raised, to save battery life.
I mapped it to cmd-shift-right so it does go to the next window. But there's no way that I could find to map going to the previous window... So for example I might have two windows tiled side by side. I want to go cmd-shift-right to focus on the right one, and cmd-shift-left to focus on the left...
From other comments, it seems like yabai can also handle it, but it seems like a very "hard-core" way, including disabling some Mac security features, and I'm not sure I feel comfortable going that far yet :)
Also, Cmd+` goes to the next window, Cmd+Shift+` goes to the previous window, your mappings having a shift in them might be the issue.
No. But I don't think it's too much to ask to cycle through more than two, now, is it? :)
> Also, Cmd+` goes to the next window, Cmd+Shift+` goes to the previous window, your mappings having a shift in them might be the issue.
I'm not sure I understand how having a shift in my mapping affects this, but cmd-shift-` isn't ergonomic at all. To me the arrows are far more logical way to go in a certain direction. Why can I map next window to any key, but there's no way to map another key to the previous window? I find it very strange.
For the sake of comparison, i3 makes all those things trivial.
You might find it useful as a starting point or as a source of inspiration.
Have you, by any chance, tried Hammerspoon (hammerspoon.org)? That seems to be tool with a broader feature set compared to Phoenix. I was looking for some kind of well analyzed and written comparison.
https://en.wikipedia.org/wiki/System_6#MacroMaker
http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...
The frontier was to eventually make everything scriptable and deterministic by getting more apps to have hooks that could be controlled directly (so like a specific command to click the close box of a window for example, rather than sending a click event right and down from the top left corner).
Anyway, this whole concept of how to use computers seems to be all but dead today and I can't help but feel that something of tremendous value has been lost. Please, if you ever write macro tools like Phoenix, add a record feature.
For Windows, there is a macro scripting language Autohotkey [0], which has powerful recording GUIs built on it [1]. Although it doesn't support application-specific hooks that I'm aware of, it does allow introspection into the rendered GUI of the application, so you can "click a button" instead of "click a pixel".
OS X has Keyboard Maestro [2], which I've heard is good.
Also, many keyboards have macro recording built in. My Ducky keyboard can record and save macros with no custom software/driver needed. (the macros can even include mouse clicks, but that's a little janky.)
As a final note, I think the place I've seen macro recording still used the most is in gaming. In most other areas of computing, it's seen as preferable to make a special-purpose utility to solve a problem instead of building layers of automation on top of a more general-purpose tool.
(btw, this is just based on my personal experience -- I love automation so I've never been far from the macro-space. I'm not trying to argue against your point.)
[0]: https://www.autohotkey.com/
[1]: https://www.macrocreator.com/
[2]: https://www.keyboardmaestro.com/main/
Yeah, in general the opinion seems to be "you want to manually do stuff, use a GUI. If you want automation, use the API of either a server-side backend or CLI tool", but there is a huge segment of users that are between that. Imagine power users that don't know how to program. For them to be able to quickly record > playback some common thing they do, would save a lot of time and be valuable
That and “highlight-to-copy” “middle-click-to-paste” are two things I really miss from an X11 environment.
This is true, but easily surmountable.
Mondomouse, which is the last bona-fide focus-follows-mouse add-on that existed for OSX (circa snow leopard) had a switch timer that was user-definable.
So you could set the switch timer to .5 seconds or 1 second or something which would allow you to run the mouse across other windows without changing focus. That solved the menu bar problem that you are, correctly, pointing out.
I think it's also worth mentioning that if you're at the point where you're demanding FFM, you're probably already doing everything with hotkeys anyway so it's not like you're running up to the menu bar often ...
I used to achieve FFM, circa snow-leopard, with the excellent "mondomouse" from AtomicBird, but it is no longer maintained and will not work with modern OSX versions.
Looking ahead, it appears that there is some new capability buried deep inside the accessibility section of Preferences that actually enables FFM, but I do not have a new enough (Mojave ?) version of OSX to verify this ...
EDIT: I think it is actually High Sierra that this new accessibility feature appeared in, but again, not sure ...
[1]: https://news.ycombinator.com/item?id=22143917
[1]ianyh.com/amethyst
https://www.spectacleapp.com/
With Spectacle, the default keybinds are using Alt and Cmd as super key. I like that one; I rather keep Caps Lock as Esc (else I'd use it as Ctrl).
As for i3, there's a backwards compatible Wayland successor called Sway [2].
[1] https://github.com/eczarny/spectacle
[2] https://github.com/swaywm/sway
Why not both? My caps is esc when pressed alone, but it’s ctrl when pressed in combination with other keys. :)
The links are for WM configurations that let you move or resize windows keeping the corners on a configurable grid:
[1] https://github.com/luigirizzo/lrtile-chrome (chrome extension) Ctrl+Shift+Arrow move the current window, Ctrl+Search+Arrows resize it
[2] https://github.com/luigirizzo/lrtile-cinnamon (cinnamon extension, linux) Alt+Arrows move the current window, Shift+Arrows resize it(I have a similar Javascript configuration for Spectacle, I can post it if there is interest. I believe the javascript is easily portable to other scriptable window managers.)
My rationale for developing lrtile is the following:
I like having window corners on a grid because it helps locating information.
However, in many tiled WMs, resizing one window causes resizing of nearby ones (very distracting) _and_ windows generally do not overlap (a severe limitation especially on small screen). Finally, shortcuts to place windows on half or a quarter of the screen are often built-in (in chrome, windows, spectacle default...) but very few WMs have larger, configurable grids suitable for large monitors (I use a 40" 4K screen).
lrtile addresses the above problems as follows:
- the grid is configurable; - movement/resize only affect the current window, allowing overlap if user wants; - commands are arrows + 1/2 modifiers, and try to be intuitive - screen borders act as hard stops, also making behavior more intuitive.
In detail, I typically use a 6x6 grid on small screens (so I can have halves or thirds) and 12x10 or even bigger on large screens. Each window side must be at least two units, and resize extends or reduces one dimension at a time and by one unit.
My typical workflow is to make windows visible with a comfortable size and no overlap, and occasionally expand the window I care about (e.g. make the browser wider when a page does not render well; or expand the editor window vertically when I want to see a larger chunk of code), reverting back when done. The fact that move and resize commands are very similar to other cursor movements makes the operation very quick.
[0]: https://github.com/aleksandar-todorovic/awesome-linux/blob/m...
https://developer.gnome.org/gnome-devel-demos/stable/dialog....
Dear god, why? Don’t I have to suffer enough in my day job?
For real though this is a cool project despite my own personal JavaScript fatigue.
[0]: https://www.phoenixframework.org
And on a less nit-pick-y note if the author is reading this - the project looks really fun and is certainly going to take up a chunk of my weekend!