Fix stack icon rendering on newer macOS

[kiwidream]

Summary

Fix stack indicators not showing app icons on newer macOS/Hammerspoon setups, and add a small local Lua test harness to cover the new behavior.

Fixes#125.

Problem

On current Apple Silicon and newer macOS/Hammerspoon environments, Stackline could fail to display stack icons for two different reasons:

1. paths.yabai could point at a Homebrew prefix directory such as /opt/homebrew/opt/yabai instead of the actual binary, which caused the hs.task launch to fail and left stackmanager empty.
2. Even when yabai was reachable, Stackline relied on hs.window.filter:getWindows() to expose every stacked window. On newer setups that assumption appears less reliable, so Stackline could miss stacked windows before it ever reached the icon drawing path.
3. The icon lookup path itself used hs.appfinder.appFromName(), which is deprecated and can return nil in cases where the owning application object is already available from the window.

The net effect was that users could create a stack successfully but see no icon indicators, with very little diagnostic information about which layer had actually failed.

Solution

This PR hardens the stack detection and icon lookup paths:

• resolve the configured yabai path more defensively, including handling directory-style Homebrew paths and falling back to common binary locations
• surface one-time user notifications when yabai cannot be found or launched, instead of failing silently
• treat yabai as the source of truth for stack-index values and drop grouped windows that yabai does not report as stacked
• rebuild stacks from yabai window IDs on active spaces when hs.window.filter does not expose all stacked windows
• switch icon lookup to use the live window application object first, then fall back to bundle ID, app path, and hs.application.get() as needed
• cache resolved icon images per window to avoid repeating lookup work
• update the default paths.yabai config to prefer /opt/homebrew/bin/yabai when present

Additional Changes

This PR also adds a lightweight local Lua test harness so the new behavior can be exercised without requiring a full interactive Hammerspoon session:

• make test entrypoint
• focused unit tests for default yabai path selection
• focused unit tests for query fallback and path resolution
• focused unit tests for icon lookup fallback and caching

Testing

Manual:

• validated the fix locally with Hammerspoon running from ~/.hammerspoon
• confirmed Stackline loads via the hs CLI after enabling hs.ipc
• confirmed the patched config resolves paths.yabai to /opt/homebrew/bin/yabai

Automated:

make test

Current result:

• 6 tests, 0 failures

[kiwidream]

Summary

Fix stack indicators not showing app icons on newer macOS/Hammerspoon setups, and add a small local Lua test harness to cover the new behavior.

Fixes#125.

Problem

On current Apple Silicon and newer macOS/Hammerspoon environments, Stackline could fail to display stack icons for two different reasons:

1. paths.yabai could point at a Homebrew prefix directory such as /opt/homebrew/opt/yabai instead of the actual binary, which caused the hs.task launch to fail and left stackmanager empty.
2. Even when yabai was reachable, Stackline relied on hs.window.filter:getWindows() to expose every stacked window. On newer setups that assumption appears less reliable, so Stackline could miss stacked windows before it ever reached the icon drawing path.
3. The icon lookup path itself used hs.appfinder.appFromName(), which is deprecated and can return nil in cases where the owning application object is already available from the window.

The net effect was that users could create a stack successfully but see no icon indicators, with very little diagnostic information about which layer had actually failed.

Solution

This PR hardens the stack detection and icon lookup paths:

• resolve the configured yabai path more defensively, including handling directory-style Homebrew paths and falling back to common binary locations
• surface one-time user notifications when yabai cannot be found or launched, instead of failing silently
• treat yabai as the source of truth for stack-index values and drop grouped windows that yabai does not report as stacked
• rebuild stacks from yabai window IDs on active spaces when hs.window.filter does not expose all stacked windows
• switch icon lookup to use the live window application object first, then fall back to bundle ID, app path, and hs.application.get() as needed
• cache resolved icon images per window to avoid repeating lookup work
• update the default paths.yabai config to prefer /opt/homebrew/bin/yabai when present

Additional Changes

This PR also adds a lightweight local Lua test harness so the new behavior can be exercised without requiring a full interactive Hammerspoon session:

• make test entrypoint
• focused unit tests for default yabai path selection
• focused unit tests for query fallback and path resolution
• focused unit tests for icon lookup fallback and caching

Testing

Manual:

• validated the fix locally with Hammerspoon running from ~/.hammerspoon
• confirmed Stackline loads via the hs CLI after enabling hs.ipc
• confirmed the patched config resolves paths.yabai to /opt/homebrew/bin/yabai

Automated:

make test

Current result:

• 6 tests, 0 failures

[kiwidream]

Summary

Fix stack indicators not showing app icons on newer macOS/Hammerspoon setups, and add a small local Lua test harness to cover the new behavior.

Fixes#125.

Problem

On current Apple Silicon and newer macOS/Hammerspoon environments, Stackline could fail to display stack icons for two different reasons:

1. paths.yabai could point at a Homebrew prefix directory such as /opt/homebrew/opt/yabai instead of the actual binary, which caused the hs.task launch to fail and left stackmanager empty.
2. Even when yabai was reachable, Stackline relied on hs.window.filter:getWindows() to expose every stacked window. On newer setups that assumption appears less reliable, so Stackline could miss stacked windows before it ever reached the icon drawing path.
3. The icon lookup path itself used hs.appfinder.appFromName(), which is deprecated and can return nil in cases where the owning application object is already available from the window.

The net effect was that users could create a stack successfully but see no icon indicators, with very little diagnostic information about which layer had actually failed.

Solution

This PR hardens the stack detection and icon lookup paths:

• resolve the configured yabai path more defensively, including handling directory-style Homebrew paths and falling back to common binary locations
• surface one-time user notifications when yabai cannot be found or launched, instead of failing silently
• treat yabai as the source of truth for stack-index values and drop grouped windows that yabai does not report as stacked
• rebuild stacks from yabai window IDs on active spaces when hs.window.filter does not expose all stacked windows
• switch icon lookup to use the live window application object first, then fall back to bundle ID, app path, and hs.application.get() as needed
• cache resolved icon images per window to avoid repeating lookup work
• update the default paths.yabai config to prefer /opt/homebrew/bin/yabai when present

Additional Changes

This PR also adds a lightweight local Lua test harness so the new behavior can be exercised without requiring a full interactive Hammerspoon session:

• make test entrypoint
• focused unit tests for default yabai path selection
• focused unit tests for query fallback and path resolution
• focused unit tests for icon lookup fallback and caching

Testing

Manual:

• validated the fix locally with Hammerspoon running from ~/.hammerspoon
• confirmed Stackline loads via the hs CLI after enabling hs.ipc
• confirmed the patched config resolves paths.yabai to /opt/homebrew/bin/yabai

Automated:

make test

Current result:

• 6 tests, 0 failures

[kiwidream]

Summary

Fix stack indicators not showing app icons on newer macOS/Hammerspoon setups, and add a small local Lua test harness to cover the new behavior.

Fixes#125.

Problem

On current Apple Silicon and newer macOS/Hammerspoon environments, Stackline could fail to display stack icons for two different reasons:

1. paths.yabai could point at a Homebrew prefix directory such as /opt/homebrew/opt/yabai instead of the actual binary, which caused the hs.task launch to fail and left stackmanager empty.
2. Even when yabai was reachable, Stackline relied on hs.window.filter:getWindows() to expose every stacked window. On newer setups that assumption appears less reliable, so Stackline could miss stacked windows before it ever reached the icon drawing path.
3. The icon lookup path itself used hs.appfinder.appFromName(), which is deprecated and can return nil in cases where the owning application object is already available from the window.

The net effect was that users could create a stack successfully but see no icon indicators, with very little diagnostic information about which layer had actually failed.

Solution

This PR hardens the stack detection and icon lookup paths:

• resolve the configured yabai path more defensively, including handling directory-style Homebrew paths and falling back to common binary locations
• surface one-time user notifications when yabai cannot be found or launched, instead of failing silently
• treat yabai as the source of truth for stack-index values and drop grouped windows that yabai does not report as stacked
• rebuild stacks from yabai window IDs on active spaces when hs.window.filter does not expose all stacked windows
• switch icon lookup to use the live window application object first, then fall back to bundle ID, app path, and hs.application.get() as needed
• cache resolved icon images per window to avoid repeating lookup work
• update the default paths.yabai config to prefer /opt/homebrew/bin/yabai when present

Additional Changes

This PR also adds a lightweight local Lua test harness so the new behavior can be exercised without requiring a full interactive Hammerspoon session:

• make test entrypoint
• focused unit tests for default yabai path selection
• focused unit tests for query fallback and path resolution
• focused unit tests for icon lookup fallback and caching

Testing

Manual:

• validated the fix locally with Hammerspoon running from ~/.hammerspoon
• confirmed Stackline loads via the hs CLI after enabling hs.ipc
• confirmed the patched config resolves paths.yabai to /opt/homebrew/bin/yabai

Automated:

make test

Current result:

• 6 tests, 0 failures

[kiwidream]

Summary

Fix stack indicators not showing app icons on newer macOS/Hammerspoon setups, and add a small local Lua test harness to cover the new behavior.

Fixes#125.

Problem

On current Apple Silicon and newer macOS/Hammerspoon environments, Stackline could fail to display stack icons for two different reasons:

1. paths.yabai could point at a Homebrew prefix directory such as /opt/homebrew/opt/yabai instead of the actual binary, which caused the hs.task launch to fail and left stackmanager empty.
2. Even when yabai was reachable, Stackline relied on hs.window.filter:getWindows() to expose every stacked window. On newer setups that assumption appears less reliable, so Stackline could miss stacked windows before it ever reached the icon drawing path.
3. The icon lookup path itself used hs.appfinder.appFromName(), which is deprecated and can return nil in cases where the owning application object is already available from the window.

The net effect was that users could create a stack successfully but see no icon indicators, with very little diagnostic information about which layer had actually failed.

Solution

This PR hardens the stack detection and icon lookup paths:

• resolve the configured yabai path more defensively, including handling directory-style Homebrew paths and falling back to common binary locations
• surface one-time user notifications when yabai cannot be found or launched, instead of failing silently
• treat yabai as the source of truth for stack-index values and drop grouped windows that yabai does not report as stacked
• rebuild stacks from yabai window IDs on active spaces when hs.window.filter does not expose all stacked windows
• switch icon lookup to use the live window application object first, then fall back to bundle ID, app path, and hs.application.get() as needed
• cache resolved icon images per window to avoid repeating lookup work
• update the default paths.yabai config to prefer /opt/homebrew/bin/yabai when present

Additional Changes

This PR also adds a lightweight local Lua test harness so the new behavior can be exercised without requiring a full interactive Hammerspoon session:

• make test entrypoint
• focused unit tests for default yabai path selection
• focused unit tests for query fallback and path resolution
• focused unit tests for icon lookup fallback and caching

Testing

Manual:

• validated the fix locally with Hammerspoon running from ~/.hammerspoon
• confirmed Stackline loads via the hs CLI after enabling hs.ipc
• confirmed the patched config resolves paths.yabai to /opt/homebrew/bin/yabai

Automated:

make test

Current result:

• 6 tests, 0 failures

[kiwidream]

Summary

Fix stack indicators not showing app icons on newer macOS/Hammerspoon setups, and add a small local Lua test harness to cover the new behavior.

Fixes#125.

Problem

On current Apple Silicon and newer macOS/Hammerspoon environments, Stackline could fail to display stack icons for two different reasons:

1. paths.yabai could point at a Homebrew prefix directory such as /opt/homebrew/opt/yabai instead of the actual binary, which caused the hs.task launch to fail and left stackmanager empty.
2. Even when yabai was reachable, Stackline relied on hs.window.filter:getWindows() to expose every stacked window. On newer setups that assumption appears less reliable, so Stackline could miss stacked windows before it ever reached the icon drawing path.
3. The icon lookup path itself used hs.appfinder.appFromName(), which is deprecated and can return nil in cases where the owning application object is already available from the window.

The net effect was that users could create a stack successfully but see no icon indicators, with very little diagnostic information about which layer had actually failed.

Solution

This PR hardens the stack detection and icon lookup paths:

• resolve the configured yabai path more defensively, including handling directory-style Homebrew paths and falling back to common binary locations
• surface one-time user notifications when yabai cannot be found or launched, instead of failing silently
• treat yabai as the source of truth for stack-index values and drop grouped windows that yabai does not report as stacked
• rebuild stacks from yabai window IDs on active spaces when hs.window.filter does not expose all stacked windows
• switch icon lookup to use the live window application object first, then fall back to bundle ID, app path, and hs.application.get() as needed
• cache resolved icon images per window to avoid repeating lookup work
• update the default paths.yabai config to prefer /opt/homebrew/bin/yabai when present

Additional Changes

This PR also adds a lightweight local Lua test harness so the new behavior can be exercised without requiring a full interactive Hammerspoon session:

• make test entrypoint
• focused unit tests for default yabai path selection
• focused unit tests for query fallback and path resolution
• focused unit tests for icon lookup fallback and caching

Testing

Manual:

• validated the fix locally with Hammerspoon running from ~/.hammerspoon
• confirmed Stackline loads via the hs CLI after enabling hs.ipc
• confirmed the patched config resolves paths.yabai to /opt/homebrew/bin/yabai

Automated:

make test

Current result:

• 6 tests, 0 failures

[kiwidream]

Summary

Fix stack indicators not showing app icons on newer macOS/Hammerspoon setups, and add a small local Lua test harness to cover the new behavior.

Fixes#125.

Problem

On current Apple Silicon and newer macOS/Hammerspoon environments, Stackline could fail to display stack icons for two different reasons:

1. paths.yabai could point at a Homebrew prefix directory such as /opt/homebrew/opt/yabai instead of the actual binary, which caused the hs.task launch to fail and left stackmanager empty.
2. Even when yabai was reachable, Stackline relied on hs.window.filter:getWindows() to expose every stacked window. On newer setups that assumption appears less reliable, so Stackline could miss stacked windows before it ever reached the icon drawing path.
3. The icon lookup path itself used hs.appfinder.appFromName(), which is deprecated and can return nil in cases where the owning application object is already available from the window.

The net effect was that users could create a stack successfully but see no icon indicators, with very little diagnostic information about which layer had actually failed.

Solution

This PR hardens the stack detection and icon lookup paths:

• resolve the configured yabai path more defensively, including handling directory-style Homebrew paths and falling back to common binary locations
• surface one-time user notifications when yabai cannot be found or launched, instead of failing silently
• treat yabai as the source of truth for stack-index values and drop grouped windows that yabai does not report as stacked
• rebuild stacks from yabai window IDs on active spaces when hs.window.filter does not expose all stacked windows
• switch icon lookup to use the live window application object first, then fall back to bundle ID, app path, and hs.application.get() as needed
• cache resolved icon images per window to avoid repeating lookup work
• update the default paths.yabai config to prefer /opt/homebrew/bin/yabai when present

Additional Changes

This PR also adds a lightweight local Lua test harness so the new behavior can be exercised without requiring a full interactive Hammerspoon session:

• make test entrypoint
• focused unit tests for default yabai path selection
• focused unit tests for query fallback and path resolution
• focused unit tests for icon lookup fallback and caching

Testing

Manual:

• validated the fix locally with Hammerspoon running from ~/.hammerspoon
• confirmed Stackline loads via the hs CLI after enabling hs.ipc
• confirmed the patched config resolves paths.yabai to /opt/homebrew/bin/yabai

Automated:

make test

Current result:

• 6 tests, 0 failures

[kiwidream]

Summary

Fix stack indicators not showing app icons on newer macOS/Hammerspoon setups, and add a small local Lua test harness to cover the new behavior.

Fixes#125.

Problem

On current Apple Silicon and newer macOS/Hammerspoon environments, Stackline could fail to display stack icons for two different reasons:

1. paths.yabai could point at a Homebrew prefix directory such as /opt/homebrew/opt/yabai instead of the actual binary, which caused the hs.task launch to fail and left stackmanager empty.
2. Even when yabai was reachable, Stackline relied on hs.window.filter:getWindows() to expose every stacked window. On newer setups that assumption appears less reliable, so Stackline could miss stacked windows before it ever reached the icon drawing path.
3. The icon lookup path itself used hs.appfinder.appFromName(), which is deprecated and can return nil in cases where the owning application object is already available from the window.

The net effect was that users could create a stack successfully but see no icon indicators, with very little diagnostic information about which layer had actually failed.

Solution

This PR hardens the stack detection and icon lookup paths:

• resolve the configured yabai path more defensively, including handling directory-style Homebrew paths and falling back to common binary locations
• surface one-time user notifications when yabai cannot be found or launched, instead of failing silently
• treat yabai as the source of truth for stack-index values and drop grouped windows that yabai does not report as stacked
• rebuild stacks from yabai window IDs on active spaces when hs.window.filter does not expose all stacked windows
• switch icon lookup to use the live window application object first, then fall back to bundle ID, app path, and hs.application.get() as needed
• cache resolved icon images per window to avoid repeating lookup work
• update the default paths.yabai config to prefer /opt/homebrew/bin/yabai when present

Additional Changes

This PR also adds a lightweight local Lua test harness so the new behavior can be exercised without requiring a full interactive Hammerspoon session:

• make test entrypoint
• focused unit tests for default yabai path selection
• focused unit tests for query fallback and path resolution
• focused unit tests for icon lookup fallback and caching

Testing

Manual:

• validated the fix locally with Hammerspoon running from ~/.hammerspoon
• confirmed Stackline loads via the hs CLI after enabling hs.ipc
• confirmed the patched config resolves paths.yabai to /opt/homebrew/bin/yabai

Automated:

make test

Current result:

• 6 tests, 0 failures