feat(behaviors): persistent None/Transparent quick tiles (#16 step 1)

[numachang]

Step 1 of the key-picker rethink (#16, design note in #26). The smallest, purely-additive slice that removes the biggest friction.

What changed

• Persistent None / Transparent quick tiles sit above the behavior picker and stay reachable from any keycode tab — clearing a key no longer needs a round trip through the behavior tabs. The active tile is highlighted.
• Tiles are capability-aware: resolved from the connected firmware's behaviors by displayName, so a tile only renders when that behavior exists.
• While a clear tile is active, the parameter panel now shows a live keycode grid instead of the dimmed placeholder — picking a key promotes the binding straight back to Key Press in one click. Other 0-param behaviors (Caps Word, …) keep the dimmed placeholder.

No firmware/RPC changes — output is still a BehaviorBinding through the existing doUpdateBinding path.

Tests

• npm run lint — 0 errors (pre-existing warnings only)
• tsc --noEmit — clean
• Vitest — 70 passed; adds 2 integration tests in App.edit.test.tsx covering tile persistence and the one-click Key Press promotion.

Refs #16. Builds toward the staged plan in docs/design/key-picker-rethink.md (#26).

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	zmk-studio-tweaks	a402ea7	Jun 05 2026, 03:38 PM

[numachang]

Reviewed the diff and the surrounding files. Overall this is a clean, purely-additive slice — no RPC/firmware changes, capability-aware tile resolution, good comments, and tests that document intent. Happy to see it merge. The notes below are all optional follow-ups.

1. Logic/style duplication (minor)

The new selectBehavior (BehaviorBindingPicker.tsx:277-283) is identical to the inline onClick in renderBehaviorChip (BehaviorBindingPicker.tsx:207-213) — same id !== behaviorId guard plus the setBehaviorId/setParam1(0)/setParam2(0) reset. The chip's onClick could just call selectBehavior(b.id). The quick-tile className (BehaviorBindingPicker.tsx:302-306) is also a verbatim copy of the chip className (BehaviorBindingPicker.tsx:214-218); extracting a small "selectable chip" helper would keep the two from drifting apart on a future style tweak.

2. A11y: same accessible name in two radiogroups

None/Transparent now appear as role="radio" in both the new "Quick clear" radiogroup and the "Behavior" radiogroup, so when one is active both report aria-checked=true (this is why the test moved from findByRole to findAllByRole([0])). It works, but ARIA-wise one logical selection now spans two groups. Modelling the quick tiles as aria-pressed toggle buttons instead of radios would avoid the double announcement. Note this mirrors the existing Behavior chips' pattern (native <button role="radio"> without arrow-key roving), so it's consistency rather than a regression — best handled in a separate pass if at all.

3. Confirmation only — firmware without Key Press

promoteToKeyPress is gated on keyPressId !== undefined and falls back to the dimmed placeholder otherwise (BehaviorBindingPicker.tsx:267-275). Correct and safe for a None/Transparent-only firmware. No change needed.

Tests look on point (tile persistence + one-click Key Press promotion). Items 1–2 are take-it-or-leave-it.

[numachang]

Thanks for the review! Addressed item 1 in ef6d849.

1. Duplication — done. Hoisted selectBehavior and a chipClass(selected) helper; both the quick-clear tiles and renderBehaviorChip now use them, so the reset logic and the styling can't drift apart on a future tweak.

2. A11y (radio in two groups) — deferring, per your "separate pass if at all." Beyond the consistency-with-existing-chips point, aria-pressed toggle semantics aren't a clean fit either: a key always has some behavior, so a quick tile has no "un-pressed/off" state to toggle back to (clicking an active tile is intentionally a no-op). Both role="radio" and aria-pressed are imperfect models for "shortcut to the same single selection that the Behavior group also drives." Worth solving holistically when Step 5 collapses the tab hierarchy, rather than special-casing the quick strip now.

3. Key-Press-less firmware — agreed, no change.

tsc/lint clean (pre-existing hook-deps warnings only), Vitest 70 passed.

[numachang]

Reviewed the diff: tsc --noEmit clean, vitest run src/App.edit.test.tsx green (5/5), and I traced the clearTiles threading end to end. Overall a clean, genuinely additive Step 1 that matches the design note in #26. Nice work on the shared selectBehavior/chipClass hoist, the capability-aware displayName resolution, the aria-pressed toggle (which also retires the "same name in two radiogroups" a11y note), and the added integration tests.

One design point I'd like to confirm, plus a few low-priority nits.

Design point worth confirming

From a behavior that doesn't render a keycode grid, there's no longer a one-click path to None/Transparent.

This PR drops the None/Transparent chips from the behavior groups (tieredBehaviors filters out clearIds), and the clear tiles only render inside a HID-usage grid. So when the current binding is:

• a layer behavior (&mo/&lt → ParameterValuePicker renders the layer radiogroup, no grid → no tiles), or
• another 0-param behavior like Caps Word (the dimmed-placeholder branch in BehaviorParametersPicker is not passed clearTiles),

…there is no None/Transparent anywhere on screen. Clearing the key now takes two clicks (Key Press chip → None tile) where the old chip row took one.

Net: the common Key Press → None path improves, but non-keycode starting states regress slightly. The design note accepts dropping the chips and says "Done when: from any keycode tab, one click sets &none" — which is true, but it doesn't cover the case where you're not on a keycode tab to begin with.

Is that the intended trade-off for Step 1? If we want to close the gap cheaply, passing clearTiles to the dimmed-placeholder HidUsagePicker would at least restore one-click clear from Caps Word & friends (layer behaviors would still need a separate affordance since they have no grid).

Nits (low priority)

• Search with zero matches hides the clear tiles. In the No keys match branch, trailingClearKeycapsUsage isn't rendered, so you can't clear a key while a non-matching search is active. Rendering the tiles in that branch too would keep them reachable.
• The None keycap is a fully blank cap (CLEAR_TILE_GLYPHS.None = ""), discoverable only via tooltip/aria-label. Matches the "blank = None" intent, but a totally empty cap can read as a rendering gap among the keys. A faint glyph/label might help.
• Firmware without a Key Press behavior (unrealistic): keyPressId === undefined ⇒ None/Transparent fall back to the dimmed placeholder (no clearTiles), so with the chips gone there's no way out. Not worth handling, just noting.

None of these block merge — approve-leaning once the design point above is confirmed.

🤖 Generated with Claude Code

[numachang]

Thanks for the thorough review! Addressed in da9921a.

Design point — one-click clear from non-grid states: accepting this as the Step 1 trade-off, and documented it explicitly in the design note. The common Key Press ↔ None path improves; clearing from a state that renders no keycode grid (layer behaviors, Caps Word) takes two clicks for now. I deferred the cheap partial fix (passing clearTiles to the dimmed placeholder) rather than do it half-way: it would restore one-click clear from Caps Word but not from layer behaviors, and Step 2's slot model unifies clearing across all states — so it's a cleaner place to close the whole gap at once.

Nit 1 — empty search hides the tiles: fixed. The clear tiles now render in the No keys match branch too, so a key stays clearable mid non-matching search.

Nit 2 — fully blank None cap: fixed. None now shows a faint ∅ (and both clear glyphs render at reduced opacity), so the cap reads as a special "clear" key rather than a rendering gap — while still staying visually distinct from a real keycode key.

Nit 3 / point 3 — firmware without Key Press: acknowledged, leaving as-is (unrealistic; keyPressId === undefined falls back to the dimmed placeholder).

tsc clean, Vitest 70/70.