Show HN: Phoenix – a macOS window and app manager scriptable with JavaScript
github.com
github.com
[0]https://github.com/koekeishiya/yabai [1]https://github.com/koekeishiya/skhd
On Linux I use jumpapp for the same functionality.
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.
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
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 ..
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/
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]ianyh.com/amethyst
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].
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
This works for all Chrome windows so it platform independent.
[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.
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!