You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Logs and diagnostics: confirm a copy with the kit clipboard #82
The copy actions — copying the visible log tail, the debug bundle directory, and the last archive's path — confirm that the copy happened, in the same way across all three.
Today a click writes to the clipboard and the screen does not change, so a user has no way to tell the click registered short of pasting.
Acceptance criteria
Each copy action confirms visibly without opening a new surface and without adding a control that must be dismissed.
The confirmation is reachable by assistive technology, and a repeated copy re-confirms rather than staying silent.
The copied text is byte-for-byte what the clipboard receives today, including the log tail's blank-line handling.
A copy that cannot be performed (empty tail, no archive yet) is still disabled or still produces the same refusal as now.
Notes
Small ticket. If the shared notice component from the notice ticket gives a better confirmation for one of the three, use it and say which.
Scope correction (found during implementation)
The app has two clipboard copy actions, not three. At 78e7a56 the only app clipboard writes are the logs tail (logs_view::copy_all) and the diagnostics bundle path (diagnostics_view::copy_bundle_path). There is no debug-bundle-directory copy control anywhere — the directory is only quoted in the Collect row's help text — and the only other Copy item is AppKit's editing selector for text selection, which the app cannot hook. Copying the folder is filed separately as #87.
So this ticket covers two actions, and its third bullet ("a copy that cannot be performed ... is still disabled or still produces the same refusal") applies to both.
Landed in main at 35691b2, merged from integration/kit-surface (CI green at 43223e2). Gate on the merged tree: cargo fmt --all -- --check, cargo clippy --workspace --all-targets -D warnings, cargo test --workspace — all clean.
What the reviews changed — and the biggest finding in the whole stack. The first attempt mapped a successful copy to Role::Alert and re-announced by minting a new node per press. That announces nothing: gpui-pre 0.3.10 sets no live region, and every accesskit adapter gates announcements on live != Off. So nothing this app had ever rendered was announced on any platform. This ticket's review found that and fixed it centrally — every non-quiet Notice and EmptyState is now a polite live region, mutating the element's own node in place rather than adding one, so the announce-once property #76 established still holds. Severity::Success maps to Role::Status; the confirmation keeps a stable id with the press count in both name and value (the adapters diff different fields); a stale confirmation clears when the payload changes; and the diagnostics row reserves its slot so the button cannot slide out from under the pointer.
Scope correction. Two copy actions exist, not the three this ticket assumed. The missing folder copy was filed as #87 and has since landed as #90, reshaped into a reveal in the file manager rather than a second clipboard write.
Still manual. Real screen readers on all three platforms. The platform truth is documented in the module docs: Windows announces mount and name changes, AT-SPI announces a name change on a node that stays, and macOS announces only a changed value.
Activity
docs(skills): vendor the rust and gpui-kit skills and record the UI r…
merge: adopt gpui-kit 0.8.1 and its components (#74-#82, #90)
elementalvoid commentedon Oct 31, 2026
Landed in
mainat35691b2, merged fromintegration/kit-surface(CI green at43223e2). Gate on the merged tree:cargo fmt --all -- --check,cargo clippy --workspace --all-targets -D warnings,cargo test --workspace— all clean.What the reviews changed — and the biggest finding in the whole stack. The first attempt mapped a successful copy to
Role::Alertand re-announced by minting a new node per press. That announces nothing: gpui-pre 0.3.10 sets no live region, and every accesskit adapter gates announcements onlive != Off. So nothing this app had ever rendered was announced on any platform. This ticket's review found that and fixed it centrally — every non-quietNoticeandEmptyStateis now a polite live region, mutating the element's own node in place rather than adding one, so the announce-once property #76 established still holds.Severity::Successmaps toRole::Status; the confirmation keeps a stable id with the press count in both name and value (the adapters diff different fields); a stale confirmation clears when the payload changes; and the diagnostics row reserves its slot so the button cannot slide out from under the pointer.Scope correction. Two copy actions exist, not the three this ticket assumed. The missing folder copy was filed as #87 and has since landed as #90, reshaped into a reveal in the file manager rather than a second clipboard write.
Still manual. Real screen readers on all three platforms. The platform truth is documented in the module docs: Windows announces mount and name changes, AT-SPI announces a name change on a node that stays, and macOS announces only a changed value.