NOTE: even though this update focused on performance and reliability, there are still plenty of bugs. The new a file isn't that exciting yet (it's mostly boilerplate), but I think the next update will bring the much-needed configuration mojo.
That approach is easier to think about, but it's far too slow to be useful. 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 said, yabai is invoked much less frequently in this update. 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. 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. 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.
HAMMERSPOON FIND CLOSE BUTTON FOR APP WINDOWS
Instead, it might better to update our data model to store: screens → spaces → stacks → windows … and then only update on window change events. Stacks refresh on every space/monitor change, wasting resources shelling out to yabai & redrawing all indicators from scratch. Resolved bug in which unfocused same-app windows would 'flash focus' briefly.This allowed redrawOtherAppWindows() to move into the window class, where it's less awkward. Store a reference to the stack on each window, so any window can easily call stack methods.Reduced reliance on magic numbers (indicator style is more purely from user config settings now). Centralized indicator config settings & consistent "current style" retrieval.There's a minor, barely noticable performance hit, too (not yet a problem, tho). This required a fair bit more complexity than expected, but is unavoidable (I think). 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.easier to implement enhancements that we haven't even considered yet.So, instead, I want to try try using hammerspoon's mature (if complicated) hs.window.filter and hs.window modules to achieve the same goal natively within hammerspon. This is, I presume, a side effect of stackline pummelling yabai with dozens of (mostly superfluous) query invocations. Specifically, yabai is frequently sluggish during something simple like focusing a window. I've since noticed secondary downsides, such as overall performance. Originally, I thought the main problem with relying on yabai was the 0.03s sleep required to ensure that the new window state is, in fact, represented in the query response from yabai. Window data needed to render stackline, which would have addressedĪn even better fix faster than I could _) The goal of this file is to eliminate the need to 'shell out' to yabai to query
0 kommentar(er)
