Repository navigation
feat: move the update notice into the title bar - #13
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
1. Purpose & Motivation
Description
Decision 054 gave the updater a full-width
Bannerabove the workspace, and to do it the Banner had to grow a third tone,info, meaning "read me, but nothing is wrong". That tone argued with its own component. A release announcement rendered at the same width and in the same shape as a dead engine host, and becauseBannerisshrink-0and a sibling of the resizable panel group, postponing the update cost a permanent 40px row off the editor for as long as the answer stayed "not now".This PR moves the notice into the title bar as a chip beside the Settings gear, deletes the
UpdateBannercomponent, and retires theinfotone that existed only to serve it.Context & Flow
2. Key Changes
Description
updateBanner()inrenderer/model/update.tsbecomesupdateChip(), returning{ label, detail, title, action }whereactionis"download" | "install" | null. It answers for three phases rather than two:downloadingis now showable, which is the one thing the move adds rather than relocates. A bar could not report the user's own press back at them; a chip is the control they pressed and can survive the download.UpdateChipinApp.tsxrenders inTitleBar's trailing group, before theIconButton.renderer/ui/Banner.tsxdropsinfofromBannerTone, which collapsesICON_BY_TONEto a singleWarningIconand removes the map entirely.InfoIconleavesrenderer/ui/icons.ts, which is the app's icon audit and had no other caller.Technical Decisions
The chip sits before the gear, not after it. With the chip last, the trailing flex group widens leftwards when it appears, moving the gear once a release. With the chip first, the gear stays against the right edge and the chip grows into the empty run. The first draft of decision 055 argued the opposite and was wrong; the record says so.
Its glyph is
ArrowCircleUp, notImportIcon.ImportIconis the sidebar's "Import from cURL or grpcurl" tray, four rows below in the same window.The
downloadingphase is a<span>, not a disabled<button>. Chromium emits no pointer events from a disabled button, so its tooltip never opens — and a control whose whole content is "wait" needs the tooltip more than the press.design-system.mdalready states this rule for the gRPC field lead.The accent stops needing a carve-out. Decision 054 had to argue the banner was the one place the accent appeared without being the thing the user came to press. In the chrome it is that thing, and it is the only accent in the row.
Critical Modules/Files
packages/desktop/src/renderer/App.tsx— the ordering insideTitleBar's trailing group is load-bearing, andUpdateChipbranches onaction === nullto pick<span>over<button>packages/desktop/src/renderer/ui/Banner.tsx— narrowingBannerToneis a public-ish change; a future non-warning tone has to reintroduce the icon map, and the docblock says sodocs/decisions/055-the-update-lives-in-the-title-bar.md— new, and amends 054's last consequence in placeRecommended Review Order
packages/desktop/src/renderer/model/update.ts— the phase-to-words mappingpackages/desktop/src/renderer/App.tsx—TitleBarandUpdateChippackages/desktop/src/renderer/ui/Banner.tsxandui/icons.ts— the deletionsdocs/decisions/055-*.md,docs/decisions/054-*.md,docs/design-system.mdtest/renderer/settings.test.ts3. Verification & Testing
Provide reproducible inputs or steps for each test case, followed by the result and supporting evidence.
All four screenshot pairs were taken by driving a built app over CDP against
test/fixtures/ws, pushing eachUpdateStatusinto the store directly. Thebeforeshots are the same build withApp.tsx,model/update.ts,ui/Banner.tsxandui/icons.tschecked out atorigin/main.With
phase: "available", the title bar shows an accent chip readingUpdate <version>immediately left of the Settings gear, and pressing it starts the downloadBefore: the full-width
infobanner, one row tall, pushing the workspace down. After: a chip in the bar the gear is already in.With
phase: "downloading", the chip readsDownloading <percent>%in neutral tone and is not pressable; with nocontent-lengthit falls back to the versionThis is the phase the move adds. Before,
updateBanner()returnednullfordownloading, so the window said nothing at all once the user pressed Download — the first shot is an empty title bar. After, the chip reports the percentage it is at.With
phase: "ready", the chip readsRestart to update <version>and pressing it quits and installsThe glyph changes to
RefreshIconand the label carries the whole verb, so the chip is readable without the tooltip.With
idle,checking,current,unsupportedorfailed, no chip renders and the Settings gear sits at the same x as when a chip is presentThe no-chip bar, to compare against the
availableshot above: the gear is at the same pixel in both. This shot is also byte-identical to thebefore-downloadingone, which is the ordering claim stated another way — with the chip ahead of the gear, its presence changes nothing to the right of it.The Settings pane's Updates section is unchanged — Skip still sits beside Download on
available4. Impact and Scope
Renderer only. No change to
packages/core,packages/cli, the engine utility process, the main process, or thepreloadbridge —UpdateStatusand its four verbs are untouched, so the updater protocol described in decision 054 still holds end to end.BannerTonenarrows from three members to two. Every remainingBannercall site passesdangerorwarn, so the change is compile-checked; a newinfocaller will failtypecheck.The workspace gains back the 40px row the banner occupied while an update was pending. The Settings pane's Updates section is unchanged, and Skip stays there — it is the one update action the chip deliberately does not carry.
A user who never looks at the title bar will not learn about an update. That is accepted in decision 055: an app that replaces itself is not so urgent that it earns a strip across the window.