Use yabai signals for events

[alin23]

Hi Adam!

I see you are already working on another branch to use hs.window.filter everywhere, so this PR will mostly serve as a reference if you have already made up your mind about that.

This PR does the following:

• Use yabai signals along with hs.ipc for checking for changes at the right time
  • this fixes the sleep problem as the changes are always present before yabai sends the signal
  • it also reacts to changes in window/gap/padding size
• Use the already optimised /bin/dash instead of the brew installed /usr/local/bin/dash. The default /bin/dash starts almost twice as fast as you can see in the below screenshot:
  
• Install stackline by directly cloning it into the ~/hammerspoon directory
  • the current instructions have a mistake: require "stackline.stackline.core" expects the whole repo, not separate symlinks
• Fixes the use of path_helper which outputs executable sh code, not a PATH value
• Makes showIcons configurable through hs.settings
  • To toggle icons: echo ":toggle_icons:1" | hs -m stackline-config
• Add some padding to the icons layout
• Remove some debug messages as everything seems to work perfectly fine and makes the code easier to parse and edit

This is how icons look right now (pills look the same so no need for a screenshot):

This is what one would need to add in their .yabairc for the signals:

STACKLINE_EVENTS="\
    application_activated \
    application_front_switched \
    application_hidden \
    application_launched \
    application_terminated \
    application_visible \
    window_created \
    window_deminimized \
    window_focused \
    window_minimized \
    window_resized"

yabai -m signal --add \
    event="window_destroyed" \
    label="stackline_window_destroyed" \
    action="echo ':window_destroyed' | /usr/local/bin/hs -m stackline-events"

for event in $STACKLINE_EVENTS
do
    yabai -m signal --add \
        event="$event" \
        label="stackline_$event" \
        app!="Hammerspoon" \
        action="echo ':$event' | /usr/local/bin/hs -m stackline-events"
done

fixes #12 #9

[AdamWagner]

@alin23 !!

These changes are AWESOME! Thank you!

I just read through all the changes, and they look very very good. I'm going to merge this so anyone who's trying this out has a less bad experience :-)

Some more specific thoughts:

Use yabai signals along with hs.ipc for checking for changes at the right time
this fixes the sleep problem as the changes are always present before yabai sends the signal
it also reacts to changes in window/gap/padding size

Ha! My v0 prototype used signals + hs.ipc. The performance wasn't great, and I also had issues with excessive re-stacking causing flicker. I think this was due to tons of yabai signals being fired and not debounced. The move to Hammerspoon's window filter was an attempt to fix these issues, which caused other issues. The way you've weaved yabai signals back into the mix to patch up those issues is pretty neat.

It doesn't seem many people know about the Hammerspoon ipc tool, so nice find!

Use the already optimised /bin/dash instead of the brew installed /usr/local/bin/dash. The default /bin/dash starts almost twice as fast as you can see in the below screenshot:

Oops! Just a minute while I change all of my hashbangs… haha.
My system is far from stock, and I was worried that I had forgotten a dependency here or there. Thanks for catching/fixing this, and for helping out johnallen3d to get it running.

Install stackline by directly cloning it into the ~/hammerspoon directory
the current instructions have a mistake: require "stackline.stackline.core" expects the whole repo, not separate symlinks

Yea. Not only is it unnecessary to symlink (from ~/Downloads?!), I just plain messed up the instructions in the readme. Big improvement.

Fixes the use of path_helper which outputs executable sh code, not a PATH value

This is the only one that confuses me. 🤨️ I'll followup with a gif of running path_helper and getting a path setting output as a string. Not sure what's going on here. Would be nice to avoid eval if possible.

Makes showIcons configurable through hs.settings
To toggle icons: echo ":toggle_icons:1" | hs -m stackline-config

This is just great! I wanted to create an issue for reading from a settings file yesterday, but forgot. You implemented it before I could do it tonight!

The icons look really really excellent.

I'll test this real quick and then merge. Thanks again!

---

PS:

But @AdamWagner is already in the middle of a big refactor to ditch the shell script so this might get more stable in the next few days.

Tis true. I have a lot of local changes that I haven't pushed yet, but it's looking promising. MUCH better performance when switching the focused window within a stack. Also, tracking the state of hammerspoon window objects instead of ingesting json and building our own window objects cleans up a lot of stuff. Also, I discovered hs.timer.delayed which, ahem: "Is a specialized timer objects to coalesce processing of unpredictable asynchronous events into a single callback". That's exactly what I had been looking for to fix the excessive re-stacking issue I had when using yabai signals, and still had to some degree when using hammerspoon's window filters.

The major problem I ran into is that the premise of #8 isn't true: There's a key bit of info that only (as far as I can tell) exists in yabai: stack index.

Hammerspoon window filters order windows by last focused by default, which causes the indicators to appear as if they aren't changing when they're actually changing and reordering (I wasted a lot of time trying to solve the wrong problem there).

That said, I actually think most of your changes here will survive (settings, icon beautification, and even some of the yabai signals).

[AdamWagner]

Here's a gif of path_helper spitting out the path as a string that could be assigned to PATH. I wonder why we're experiencing different things here?

[AdamWagner]

Okay! Everything should be merged in. I added your yabai signals, toggle_icons command, and improved icons screenshot to the readme (I hope it's okay that I used the image).

Can you confirm that the flicker seen in the gif below is also present on your system? Just want to make sure it's not caused by something weird in my setup.

[alin23]

@AdamWagner the path_helper man specifically says that it outputs shell commands for evaluating. I can also see that in your gif, you can see the ; export PATH code in the output which clearly does not make sense to be assigned to the PATH variable.

Eval is not that wild, a lot of other init scripts use it (ssh-agent, pyenv, gpg-agent etc.) and path_helper is a system binary living in a read-only path which should be as secure as you can have it.

About the flicker, it is caused by the window_destroyed signal which does not have an app!= filter to filter out Hammerspoon window events.
I've fixed that here: #14

But of course, this means that closing a window leaves the stackline with a window that does not exist anymore.
Until I can think of a proper solution, I'm working around that by adjusting the yabai gap size which triggers a window_resize event and recreates the stack

[alin23]

Thanks for merging this! I did not expect that, seeing how much work you've put into using Hammespoon's window events.
It's still not perfectly snappy, but I think that's the best we can get given that we're not running C code inside the yabai process. Shells and Lua scripting will always have a small visible delay.

[AdamWagner]

the path_helper man specifically says that it outputs shell commands for evaluating

Shame on me for not RTFM ;-) . I think what tripped me up is that PATH=$(/usr/libexec/path_helper) still seems to work for me. I use it often enough that I even have it saved as an Alfred snippet. Without that snippet, scripts that don't inherit the environment fail. With it, they succeed. Nonetheless, it's clearly the wrong way to use it, so thanks for calling this out. TIL.