Query window data entirely in hammerspoon instead of shelling out to yabai?

[AdamWagner]

Today I learned that hammerspoon window objects also have a frame property (alongside many others: hs.window docs).

Especially since we're we're grouping windows into stacks manually by grouping on frame.x and frame.y (due to yabai lacking a stack_id property), there's really no reason that we need to call out to yabai -m query …

(I think) this would resolve #9 .

[AdamWagner]

This approach is 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 (query window data entirely in hammerspoon) isn't possible: There's a key bit of info that only (as far as I can tell) exists in yabai: window.stack-index. The stack index stores the position of a window within a stack, and is critical for drawing the indicators in the correct order. If anyone has an idea for how to infer this without querying yabai, I'm all ears.

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).

Unless we find a way to infer stack index without yabai, I'm querying yabai just once on space switch, which is better than querying it on every single window event.

[AdamWagner]

This last push improves performance & reliability, and even some new functionality:

• Hammerspoon is now responsible for querying and processing macOS window data. Hammerspoon's ability to coalesce the swarm of asynchronous change events that were causing your fans to spin up is a major improvement over calling yabai -m query --windows --space … dozens of times a minute. The move also made it possible to take a more traditional OOP approach, which has made tracking and mutating all of this desktop state a bit simpler. Unfortunately, it's still necessary to call out yabai, as it's the the keeper of each window's stack-index — a key bit of info that, afaict, is neither available elsewhere nor inferrable. That said, yabai is invoked much less frequently in this update.
• In addition to only updating data when it's actually necessary, special attention has been given to changing focus within a stack: the POC blew away all of the UI state and _regenerated it from scratch … every … time … a window gained/lost focus. That approach is easier to think about, but it's far too slow to be useful. In this version, indicators should be snappy when changing focus :)

There's also some fun new functionality:

• Stack indicators are always positioned on the side of the window that's closest to the edge of the screen. This allows for tight window_gaps, — even with showIcons enabled.
• Magic numbers are less entangled in the implementation details (though it's still pretty bad) — and a few of them have even been abstracted into easy-to-mess with configuration settings. The new config.lua file isn't that exciting yet (it's mostly boilerplate), but I think the next update will bring the much-needed configuration mojo.

[AdamWagner]

Update 2020-08-16

Changes

• Support stack focus "events"! Now, a stack takes on a new look when all windows become unfocused, with the last-active window distinct from the rest. This required a fair bit more complexity than expected, but is unavoidable (I think). There's a minor, barely noticeable performance hit, too (not yet a problem, tho).
• Centralized indicator config settings & consistent "current style" retrieval. Reduced reliance on magic numbers (indicator style is more purely from user config settings now).
• Store a reference to the stack on each window, so any window can easily call stack methods. This allowed redrawOtherAppWindows() to move into the window class, where it's less awkward.
• Resolved bug in which unfocused same-app windows would 'flash focus' briefly

Multi-monitor support is still a ?

Stacks refresh on every space/monitor change, wasting resources shelling out to yabai & redrawing all indicators from scratch.

Instead, it might better to update our data model to store: screens[] → spaces[] → stacks[] → windows[] … and then only update on window change events.

[AdamWagner]

Closed by #18