Flowlight 0.8.1

[blessdyb]

Two fixes to one symptom: macOS listing Flowlight under Using Significant Energy while it sat idle in the menu bar. Measured 6.3% of a core at idle, 37% averaged over three and a half hours.

Occlusion, not view lifecycle

The live chart series and the per-app list were already gated on uiVisible — but that was driven by SwiftUI's onAppear/onDisappear, which only say a window exists. It stays "appeared" while the window is minimised, fully covered by another app, or on a Space nobody is looking at. In all three, the chart was rebuilt every second for an audience of nobody.

It now follows NSWindow.occlusionState, which is the state that actually answers "can anyone see this".

The counter became a set

Occlusion notifications are not guaranteed to pair up. A window closed while already occluded, or one missed teardown, leaks a count — and a leaked count pins visibility to true for the rest of the session, silently restoring the cost the gate exists to remove. Keying on window identity makes every update idempotent.

WindowVisibility is its own type so the state machine is testable without constructing a TrafficMonitor, whose init opens the real traffic database.

SMAppService out of a @State default

SettingsView read "launch at login" in a property's default value:

@State private var launchAtLogin = SMAppService.mainApp.status == .enabled

That expression re-runs every time the view struct is constructed, and Settings { } is rebuilt whenever the App body is invalidated — which TrafficMonitor did every second through its @Published properties. SMAppService.status is a synchronous XPC round trip to smd, so this put blocking IPC on the main thread at 1 Hz for the life of the process, whether or not Settings was ever opened.

A sample caught the whole chain:

AppBodyAccessor.updateBody(of:changed:)
  Settings.init(content:)
    SettingsView.init
      -[SMAppService status]
        _send_smd_request
          _xpc_pipe_routine

Now read in .task, once, when the pane appears.

Tests

470 pass, including five new ones covering the drift cases a counter could not survive: repeated notifications for one window, hiding a window that was never visible, and two windows closing in either order.