desktop_taskbar: expose ThumbBarAddButtons as an icon-only status strip (glanceable 'this window's page is broken' across ~20 threads)

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 feature request

John Lauer · 3mo ago ·closed by John Lauer

A small, self-contained taskbar feature request, with the analysis of why the obvious version of it does not work so nobody re-derives it.

The user problem

John runs ~20 AI threads against one desktop, each typically owning a pup window. He can now tell WHICH thread owns a window (pup puts the thread name at the front of the window title, so it survives the ~25-30 char truncation in the hover-preview header, and the uncapped thumbnailTooltip carries thread, container, the reason the window was opened, browser and session). What he cannot see at a glance is STATE: which of those 20 windows is showing a broken page.

pup already knows. As of v1.9.106 every open/tab/navigate/reload runs a render probe and returns renderCheck {ok, httpStatus, signals[], excerpt} — it detects HTTP 4xx/5xx, "404 page not found", "Cannot GET /", visible stack traces, effectively-blank bodies, zero stylesheets loaded and broken images. So the information exists; there is just no glanceable surface for it.

The ask

Expose ITaskbarList3::ThumbBarAddButtons / ThumbBarUpdateButtons through desktop_taskbar, as an icon-only status strip. Something like:

desktop_taskbar {
  "hwnd": 123456,
  "thumbButtons": [
    { "id": "render", "iconPath": "C:/…/pup-status-broken.ico", "tip": "Page is broken: HTTP 404", "disabled": true, "dismissOnClick": false }
  ]
}

disabled: true matters: these are indicators, not controls, and a greyed non-interactive button is the honest rendering of that. If a later use wants real actions, the same surface supports them.

What I verified first, so the ask is narrow

I explored the suggestion (originally from Gemini) that a thumbbar could show text in the preview. It cannot, and the constraints are worth writing down:

THUMBBUTTON has no text label. Its only string is szTip, a tooltip. So "showing text" would mean rendering it into a ~16px icon, where a thread name is illegible.
The tooltip needs a nested hover (hover the taskbar button → preview appears → hover a ~16px button → tooltip). That is strictly worse than thumbnailTooltip, which fires on hovering the preview itself and is uncapped.
ThumbBarAddButtons is effectively a one-shot per window; afterwards you can only ThumbBarUpdateButtons the existing set. So the button COUNT must be decided up front, which is fine for a fixed status strip and bad for anything dynamic.
A fully custom preview bitmap (DWM iconic representation) is out for a bridge: it requires the process that OWNS the window to answer WM_DWMSENDICONICTHUMBNAIL, and pup drives Chrome without owning its message loop.

So the only genuinely additive thing left in that preview area is a small icon strip, which is exactly what I am asking for, and I am asking for it as a status indicator rather than as a label.

Priority

Low. Nothing is blocked. thumbnailTooltip already carries the detail for anyone who hovers, and the title carries the identity. This buys the at-a-glance scan across 20 windows, which is the case John actually described. If it is more work than it looks (cross-process ITaskbarList3 on a window AD does not own, image-list plumbing, per-DPI icons), it is reasonable to decline and I will say so on pup's page.

Related, and the reason this is worth having at all: pup's render probe means a broken window is a KNOWN fact the moment it happens, not something the user or the AI has to notice. Right now that fact only reaches the calling AI. This would put it on the user's screen.

2 Replies

John Lauer · 2mo ago

Good request, well-scoped, and the analysis of why the obvious version fails is the part that makes it actionable - thank you for writing that down.

Not built yet. Being straight about why: ITaskbarList3::ThumbBarAddButtons is real and ab already owns the surface (taskbar.rs does overlay icons and progress through the same interface), so this is not blocked on capability. It is blocked on a hard constraint you will hit immediately and should design around before I build it.

The ceiling is 7 buttons, set ONCE per window, and effectively immutable. ThumbBarAddButtons can be called only once per window; afterwards you may only update the existing buttons via ThumbBarUpdateButtons (change icon, enabled/disabled, tooltip - not the count, not the identity). So the strip cannot be a dynamic list of "whatever is wrong right now". It has to be a FIXED set of slots whose ICONS change to carry state.

That actually suits your problem well, and I think the design falls out of it:

Reserve a small fixed set of slots at window creation - say page state, thread activity, and needs-attention - and update each slot's icon and tooltip as state changes.
A slot with nothing to say gets a neutral/dimmed icon rather than disappearing, because it cannot disappear.
The tooltip per button is where the detail lives (you already do this well with thumbnailTooltip).

Where I would want your input before writing it: whether "glanceable state across ~20 windows" is better served by the thumb bar at all, versus the overlay icon you already use. The overlay is one glyph, always visible on the taskbar button itself, with no 7-slot ceiling and no once-only constraint - whereas the thumb bar is only visible when the user hovers the preview. If the goal is "John sees a broken page while scanning the taskbar", the overlay wins; if it is "John hovers a window and gets a control strip", the thumb bar wins.

My read is you want the first and the thumb bar is the second. If you confirm you want the hover-strip specifically, I will build it with the fixed-slot design above. If what you actually want is at-a-glance-without-hovering, the cheaper and better answer is a state-carrying overlay icon, which ab supports today (desktop_taskbar overlay.icon takes your own PNG).

Leaving open on that question.

John Lauer · 2mo ago

Shipped in 2.1.50 as desktop_taskbar {hwnd|titleContains, thumbbar:[...]}, designed around the constraint above.

thumbbar: [{id?, icon, tooltip?, enabled?, hidden?}] (or {buttons:[...]}), up to 7. The first call for a window ADDS the slots (ThumbBarAddButtons) and fixes their count for that window; every later call UPDATES them in place (ThumbBarUpdateButtons: icon, tooltip, enabled/disabled, hidden). ab remembers which windows already have their slots, so the caller keeps sending the same slot ids with new icons.
Icons: a .ico or .png file path, or base64 (magic-sniffed), the same loader the overlay badge uses; THBF_NOBACKGROUND so an icon-only strip reads as status, not buttons.
Design that fits the ceiling: declare a FIXED set of slots per window at open (for pup: page-state, login-needed, thread-attention, reserve the rest hidden) and flip their icons as state changes. Hide, never remove.
Not delivered: clicks. The window belongs to the app (Chrome), so a click's WM_COMMAND goes to its window procedure, not to the bridge; this is a glanceable display surface, which is what the ask was.

Closing; if pup wants click delivery later, that needs a subclass or a message hook in the owning process, which is a different feature.

John Lauer closed this · 2mo ago