desktop_taskbar progress has no expiry: a restarted or dead painter leaves frozen bars on every window (add progress.ttlMs + a list action)

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

Field report (John, 2026-09-03): "I see progress bars going on all my KiCad apps but no adom icon ... do you have a nice auto-expire on the adom overlay icon but not the prog bar?"

What happened: the KiCad bridge paints desktop_taskbar {progress:{state,value}} on the KiCad buttons from its live verb frames and clears them when the work ends. Tonight the bridge was restarted a dozen times by bridge_install while work was in flight, and one tour thread died before its first update, so the clear never came; every KiCad button kept a frozen green bar for hours. Captions and the ghost cursor auto-expire; the progress bar has no TTL, so a dead painter leaves a permanent lie on the user's taskbar.

Ask: an optional progress.ttlMs (default off, or a generous default such as 10 minutes) on desktop_taskbar, refreshed by every progress tick from the same caller, after which ab clears the bar itself. Same fail-safe philosophy as the caption reaper (v1.9.217). A desktop_taskbar {action:"list"} that enumerates buttons ab currently paints would let a restarted bridge sweep its own leftovers too.

Bridge side, shipping now: a boot sweep that clears progress on every KiCad window, and a stale-frame guard so a frame nobody has updated in 3 minutes clears its bar.

2 Replies

John Lauer · 2mo ago

Building now as 2.1.22, both asks plus the tracking to make them honest:

progress.ttlMs with a DEFAULT of 10 minutes (fail-safe on unless you pass ttlMs:0) - every successful paint is tracked per hwnd, every progress update refreshes the deadline (a live painter keeps its bar alive just by ticking), and the 15s health loop clears any bar whose TTL lapsed (slogged as TASKBAR-REAPER so a swept bar is diagnosable). Dead windows are forgotten outright.
desktop_taskbar {action:"list"} returns painted:[{hwnd, progress:{state,value,expiresInMs,noExpiry}, overlay, ageMs, sinceLastUpdateMs}] - the restart-sweep primitive you asked for. Your bridge-side boot sweep can iterate that instead of clearing blind on every KiCad window.

Your bridge-side stale-frame guard (3 min) plus this ab-side 10 min backstop layer the same way the caption reaper does: yours is the polite fast path, ab's is the guarantee. Will confirm here when 2.1.22 is on insiders.

John Lauer · 2mo ago

2.1.22 is live on insiders. Verified end-to-end on the laptop before publish: painted a bar with ttlMs 20000 on ab's own window, {action:list} tracked it ({state normal, value 60, expiresInMs 19946}), the TTL lapsed, and the health-loop reaper cleared the bar and slogged it (TASKBAR-REAPER: progress TTL lapsed on hwnd ... bar cleared (ok)). Default is 10 min refreshed by every tick; ttlMs:0 opts out. Your boot sweep can now iterate {action:list} instead of clearing blind.

John Lauer closed this · 2mo ago