The console UI answers the iPad field test — and the screen that would never open again was a UIKit read mid-render #154
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: unom/punktfunk#154
Reference in New Issue
Block a user
The Apple console/gamepad UI programme, verified on the iPad it was built for. Fifteen commits in four arcs:
The UI sized and driven for the iPad
The console UI grows a tablet tier (fonts, rows, tab strip at screen scale instead of phone scale), the legends remember which pad owns them and become clickable, pairing and the connect path's modals are fully pad-navigable (the trust prompt takes controller input; "Pairing required" / "Waiting for approval" / "Connection failed" render as console cards a pad can drive instead of system alerts a finger must dismiss), and a hardware keyboard drives the whole surface — arrows, Return, Esc — everywhere the controller already worked, plus the plain poster grid.
The regression that blocked all of it
On device (never the simulator), Settings and Add Host stopped opening: both triggers fired,
@State showSettingswas written and persisted, andGamepadHomeView.bodywas never evaluated again — no AttributeGraph warning, nothing in the log. Bisected on glass in five rounds down to one line:DisplaySafeArea.bottom, aUIApplication.shared.connectedScenes…isKeyWindowwalk executed during body, permanently severs the calling view's update graph. The@Environmentread and the negativesafeAreaInsetpadding in the same commit were proven innocent by device rounds; only the key-window walk breaks it.The landed fix measures the inset where it is knowable:
DisplayBottomInsetProbe, aUIViewRepresentablethat reads the window's bottom inset from UIKit's own callbacks and publishes\.displayBottomInsetfrom ContentView;gamepadLegendBottomPaddingis pure arithmetic. The legend-pinning commit lands already carrying this spelling, so no commit on the branch has the broken one.A trap for reviewers of future work here: a simulator gate that opens the screen programmatically (
showSettings = trueinonAppear) renders green while input-driven navigation is completely dead. Only a real press on the device tests this path.The tray gradient blur, back without the tint
The scrim deleted in
2590238breturns as a real progressive backdrop blur via Glur'sGlurBackdrop— no material stage, so nothing carries a colour over the aurora. Three deliberate calls, spelled out in the commit: it is the library's private-API product (the public modifier cannot reach a backdrop at all — worth weighing for App Store review); the dependency is pinned by revision (no release tag carriesGlurBackdrop, and the newest tag isn't semver); and the band takes no content-side overhang — Glur's ramp reaches literal zero at the tray edge, so the scrim's -44/-72 runway (which blurred fully-visible rows at rest, first on-glass verdict) is dropped rather than carried. Attributed on the Acknowledgements screen; wired into both the package manifest and the xcodeproj, which compiles these sources itself.Stream audio coexists with Music
Field report with a competitor cited doing it right: connecting paused Apple Music, and resuming Music mid-stream silenced the stream for good. One defect — the session was exclusive.
.mixWithOtherson every category path makes activation interrupt nobody and Music's resume take nothing back, and a new interruption observer revives the engines after the interrupters that remain (phone call, Siri, a non-mixable app), through the same conservative revive path the route-change and media-reset observers already use.Verification
Every claim above that says "on glass" was driven with a physical controller/finger on the iPad: Settings and Add Host open and close from real presses on the full stack, the blur band sits where it should at rest and softens rows only as they slide under the trays. 284 tests, 0 failures; macOS app build; tvOS typecheck. Main has moved host-side only since branching — the merge is clean.
Four things the field reported on glass, all in the console's visual layer. The tray scrim is GONE, not re-tuned. It laid `.ultraThinMaterial` across the top and bottom of every form screen, and a material by definition lifts and tints whatever it blurs — so it read grey, and washing it with the palette's ground only made it read coloured. There is no public way to blur a backdrop without that tint, so the layer had to go. The darkening it also provided was never its to provide: the backdrop's own legibility scrim (0.38/0.06/0.08/0.40 — the same gradient pf-console-ui bakes into its shader) has always been one layer down, which is why the console has no tray band. Pale palettes rendered every row, pill and card as a flat white slab, and lowering the tint did nothing, because the opacity came from the glass BODY: `.regular` is a bright, high-body material and a pale palette's `ink.glass` is literal white. Pale palettes take `Glass.clear` now, with a light wash to keep dark ink legible. A focused settings row changed colour in a hard jump, a beat late, while its scale animated smoothly beside it — the focus tint rode `Glass.tint`, and a Glass value is opaque to SwiftUI's animation system. It is a plain fill between the glass and the label now, so the existing animation covers it. The host cards appeared to be swapped for different ones as their entrance landed: `CardEntrance` swings each tile in on a rotation3DEffect, and Liquid Glass samples the backdrop through its own layer, which it cannot do under a 3D transform. Those tiles take the material path (`forceMaterial`). And the option band never turned like a cylinder because the band MASKED itself: a mask rasterises what it covers, flattening `rotation3DEffect`'s perspective, so the projection was computed and discarded every frame. The soft edge is folded into each option's own opacity instead. Its ±1 neighbours stay hidden at rest — showing them reproduced the documented overlap defect ("2752 × 2064" with "280 ×" through it), which is why they were dropped. Also fixes pale palettes washing out: the calm mix added a plusLighter wash of a near-white ground on top of a field already mixed toward it, saturating the form screens to white. macOS + tvOS typecheck; console UI verified opening Settings in the simulator, with no tray band.On an iPad the controls pill sat two to three times further from the bottom of the screen than from the left, so it read as floating rather than tucked into the corner. `safeAreaInset` places its content INSIDE the safe area, so the pill's bottom margin was stacking on top of the device's own ~24 pt home-indicator inset while the leading margin had nothing to stack on. Subtracting that inset is the fix; GETTING the inset is where this commit's history is. Three spellings failed before this one, each silently: - a `GeometryReader` carrying `.ignoresSafeArea()` — a proxy reports no inset for an edge it has been told to ignore, so it can only answer 0; - `.ignoresSafeArea(.container, edges: .bottom)` on the inset CONTENT, which does not move content the inset mechanism itself placed; - asking UIKit for the key window (`UIApplication.shared.connectedScenes…`) DURING body — which answers the right number and then KILLS the asking view. On a physical iPad (never the simulator) that walk re-enters UIKit layout mid-render and SwiftUI silently severs the view's update graph: from then on every `@State` write lands in storage without `body` ever running again. That is exactly how Settings and Add Host stopped opening while their triggers kept firing and `showSettings` kept reading true — no AttributeGraph warning, nothing in the log. Found by bisecting device builds; a build that opens the screen programmatically renders green with input-driven navigation completely dead, so only a real press counts. So the inset is measured where it is knowable: DisplayBottomInsetProbe, a UIView that reads its WINDOW's inset from UIKit's own callbacks (didMoveToWindow / safeAreaInsetsDidChange / layoutSubviews), hops out of the current update, and publishes through `\.displayBottomInset` from ContentView. The legend reads the environment — proven safe on glass — and `gamepadLegendBottomPadding` is pure arithmetic. Tablets only. The padding goes negative to pull the pill back down through the indicator strip, which is safe there because the pill is left-aligned and an iPad's indicator is a short bar in the middle. A phone's indicator is taller and its legend runs most of the width, so the same move would cross it — phones keep the plain margin, and the tier comes from the size classes, so an iPad in a narrow Stage Manager window is treated as the in-hand case it is. macOS + tvOS typecheck; margins and Settings/Add Host opening from a real controller press verified on the iPad itself.