10 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	a14b000c9b	feat(apple): the tray gradient blur is back — as a real blur this time ... The form screens' pinned title and legend lost their gradient blur when GamepadTrayScrim went (2590238b): the scrim was `.ultraThinMaterial`, and a material by definition lifts and tints whatever it blurs — it read grey over the aurora, and washed with the palette's ground it read coloured. There is no public way to blur a backdrop without that tint, so the layer was deleted rather than re-tuned, and the rows have scrolled to a raw edge since. Glur's GlurView blurs the backdrop through a gradient with NO material stage on top — the rows soften as they slide under the pinned trays and nothing carries a colour. Three things about the adoption are deliberate: - It is the library's GlurBackdrop product, which uses a private API (a variable-blur CAFilter on UIKit/AppKit). The public `.glur()` modifier is a Metal shader on a view's OWN content and silently no-ops over platform-backed views like ScrollView, so it cannot reach a backdrop at all. GlurBackdrop ships as a separate module precisely so adopters can weigh the App Store exposure; it disables hit testing itself, so the band never eats a touch. - The dependency is pinned by REVISION: GlurBackdrop exists only on main — no release carries it (the newest tag, `1.1`, predates it and is not three-component semver anyway, so `from:` resolution stops at 1.0.4, which doesn't have the product). Wired into BOTH manifests — the package for `swift build`, and the xcodeproj (remote package reference + per-target product deps) for the app targets, which compile these sources themselves and know nothing of Package.swift's dependencies. - The band takes NO content-side overhang, unlike the scrim it replaces — and dropping the scrim's hard-won -44/-72 runway is the point, not an oversight. That runway existed because a material carries body at every alpha and had to dissolve OUTSIDE the tray; carried over here it blurred fully-visible rows at rest (first on-glass verdict). Glur's ramp reaches literal zero, so the band ends exactly at the tray's layout edge: open content untouched, rows soften only where they actually slide under. The 80 pt outer bleed and the pinned shape (`transaction { $0.animation = nil }`) are kept — full-bleed by LAYOUT rather than `.ignoresSafeArea()`, so a push never shows the band growing into place. Mounted exactly where the scrim was: settings, add-host and pair trays (top + bottom) and the library title (top). Glur is attributed on the Acknowledgements screen alongside the bundled font — it is a Swift package, so the Rust-closure notices generator rightly knows nothing about it. macOS build, tvOS typecheck; band placement and the blur itself verified on the iPad on glass.	2026-08-10 12:46:45 +02:00
enricobuehler	3daead7d71	fix(apple): the sub-screens' legends sit where the launcher's does ... Carries the display-corner inset (previous commit) through the three screens that pin the same legend pill — settings, add-host, pair — so they don't drift from the launcher the moment the user opens one. Each of those trays is `maxWidth: .infinity, alignment: .leading`, so the pill is left-aligned there too and the iPad's short centre indicator is never in its way; the keyboard tray sits ABOVE the legend in the stack, so pulling the tray down doesn't put keycaps over the strip. And the settings tab strip now takes its padding from the row metrics instead of two fixed numbers. It was the other half of the iPad sizing complaint: the tier work grew the fields under it while the tab pills stayed at phone scale, which read as a tab bar that belonged to a different screen. macOS + tvOS typecheck. Re-landed on the probe spelling: the corner inset is read from `\.displayBottomInset` (DisplayBottomInsetProbe via ContentView), never asked of UIKit during body — the original spelling froze the update graph of any view that called it on device (see the legend-pinning commit).	2026-08-10 09:59:25 +02:00
enricobuehler	18d0009c35	feat(apple): the trust prompt takes controller input ... Trust-on-first-use had no pad wiring at all, and it appears at the worst possible moment for that: mid-connect, with capture already disabled so ContentView can blur the stream and stop forwarding. A pad-only user pressed A to connect, got this card, and found the controller in their hands doing nothing — the only way past was to reach for the screen. A trusts, B cancels, X runs the PIN ceremony instead. The legend only appears with a pad attached; naming controller buttons to a trackpad user would be describing hardware they don't have. `GamepadManager` is observed rather than read once so the bar arrives if a pad wakes up while the card is already open. Safe to poll unconditionally while the card is up: capture is off for its whole lifetime and the home screens are unmounted behind the session view, so nothing else is reading the pad. The A press that STARTED the connect is typically still held when this mounts — `GamepadMenuInput` adopts the held state without firing on start, so it doesn't auto-trust. tvOS is untouched: the focus engine already drives these buttons. macOS + tvOS typecheck.	2026-08-10 09:58:26 +02:00
enricobuehler	09bac99090	feat(apple): pairing you can actually do with a controller ... PairSheet is a `Form` with two `TextField`s. On tvOS the focus engine drives those natively, but on iOS/macOS a controller cannot reach a text field, type into it, or press the button underneath — so for anyone in the console UI, pairing (the ONE thing between a fresh install and a first stream) ended at "now touch the screen". GamepadPairView is the same ceremony in the gamepad UI's own vocabulary: the vertical focus list the settings and add-host screens use, A on a field to open GamepadKeyboard in a bottom tray, B to peel one layer. It mirrors GamepadAddHostView field for field, because it is the same interaction and someone who has added a host should recognise it immediately. The ceremony itself moved to a shared `PairCeremony` used by both presentations, so they can never disagree about what a wrong PIN means, what a host rejection says, or when a late result must be discarded. On iOS it is a shell layer like settings and add-host, and it LEADS the shell's screen order: it blocks a connect the user already asked for and can be raised from on top of the library (launching a title on an unpaired host), so it has to win; backing out reveals whatever it interrupted. macOS has no shell, so its sheet switches content by mode instead. tvOS is untouched. macOS + tvOS typecheck; console UI verified opening Settings in the iPad simulator with the pair screen wired into the shell.	2026-08-10 08:12:50 +02:00
enricobuehler	8f35155c14	fix(apple/shots): the store screenshots show the app as it actually is ... Uploading the 0.24.0 set surfaced a pair screen that reads as broken, and a hero that was never the orientation it claimed. The capture harness: - Landscape scenes were captured in PORTRAIT. `IOSOrientationConfigurator` asked for the geometry update from `updateUIViewController`, where `view.window` is still nil — SwiftUI makes one update pass for a `.background` representable, before the hierarchy is in a window, so the guard fell through and nothing ever asked again. Both `.landscape` scenes (the stream hero, the trust card) shipped as portrait. Now a real UIViewController asks from `viewDidAppear` and pins `supportedInterfaceOrientations`. - The shot host applied `.ignoresSafeArea()` to the whole scene, so the hero's HUD — resolution, bitrate, the latency breakdown, the entire point of that screenshot — sat under the Dynamic Island. Only the black backing ignores it now; scenes that want full bleed already ignore it themselves. - `03-pair` was hand-composed into a ZStack rather than presented. PairSheet is a bottom sheet on iOS: its detents and the system's Liquid Glass only exist inside a real `.sheet`. Composed, the grouped Form stretched to full screen height and the capture was a strip of content over a black void, with a DISABLED "Pair & Connect" (empty PIN) and the capture simulator's own name — `pf-shot-iphone-6.9` — rendered in as the device name. - Sheets do not inherit `.environment(\.colorScheme, .dark)` across the presentation boundary; they follow the DEVICE. The pairing sheet came out light grey over the dark app. The simulator is now set to dark appearance. - Discovery browsed the live LAN mid-capture, so a bystanding machine's hostname went out on the listing and no two runs matched. `HostDiscovery` gains a `debugSet` seam (the counterpart to `HostWaker.debugSet`); the mock hosts advertise, so cards read ONLINE through the real `advertises` path and the reachability probe never touches the network. - Created simulators were named `pf-shot-<prefix>`, which the reuse regex never matches: every run created another simulator and none was reused. They are named after the device now — reusable, and not user-visible junk. Two bugs found on the way, neither screenshot-only: - HostStore/ProfileStore PERSISTED the harness's mock data. On a dev Mac that is the same App-Group suite the real app reads, so running the script could replace the tester's saved hosts with "Battlestation" & co. - GamepadHomeView drew the controller chip as a trailing `.overlay`, which reserves no width — on a portrait phone it sat on top of the centred "Select a Host". Laid out as a row with a hidden leading mirror. - The pairing sheet's field prompt said "How the host lists this Mac" on iPhone and iPad. Coverage: the listing set is six scenes in listing order, and is now the stream, the machines it found, the couch/controller mode, waking a sleeping host, the quality controls and pairing — the console and wake screens already existed in `ShotScenes.all` and were simply never captured. Mock hosts carry OS marks, Wake-on-LAN MACs and profile chips so the grid is full rather than three offline rows over an empty half-screen. `SCENES=` overrides the set for the dev scenes.	2026-08-04 21:30:18 +02:00
enricobuehlerandClaude Opus 4.8	c131603f0d	fix(apple): point pairing copy at the web console's real port (47992, HTTPS) ... Every pairing surface in the Apple client still told users to open the web console on port 3000 — the pre-move port. The console has served :47992 for a long time, so anyone following the on-screen instructions hit a dead port and had no way to approve the device or read the PIN. Seven strings across ContentView, SessionModel and PairSheet (iOS/tvOS/macOS share them). The two that spell out a full URL also said `http://`; the console is HTTPS-only (host's self-signed cert), so they now read `https://<host>:47992`, matching the phrasing in the host README, install docs and the deb/rpm packaging notes. Copy-only — no behavioural change; a repo-wide sweep found no other stale :3000. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 10:17:36 +02:00
enricobuehlerandClaude Fable 5	1fc9ef0050	feat(core,host,clients): typed pairing rejections — every client says WHY, not "not accepted" ... A host's pairing-gate rejections (not armed / bound to another device / rate-limited / identity required / denied / approval timeout / superseded / wire-version mismatch) used to drop the connection with a bare code-0 close, and every client collapsed that — plus plain unreachability — into one "wrong PIN / not accepted" message. A dead network path, a disarmed host, and an operator denial were indistinguishable, which is exactly the misdiagnosis behind the recent Android pairing support thread. - core: new ungated `reject` module — shared close-code block 0x60–0x67 (+ 0x42 busy promoted from the host), `RejectReason`, and `PunktfunkError::Rejected`; `pair()`/`connect()` decode the host's ApplicationClosed code into `Rejected` instead of a generic Io error. C ABI v7: status block −20…−28 and `punktfunk_connect_ex8` (`status_out` reports the failure cause; NULL-return alone can't). Wire unchanged — old peers see exactly the old bare close. - host: every gate rejection `conn.close()`s with its typed code (and the human reason as close bytes) before erroring out of the session task. - pf-client-core: shared `pair_error_message`/`connect_reject_message` wording consumed by the Windows + Linux + console-UI + CLI surfaces; a connect failure now renders the host's stated reason. - android: `nativeTakeLastError()` JNI token + `ConnectErrors.kt` — a network timeout is no longer reported as "wrong PIN, or the host isn't armed", and a typed rejection skips the wake-and-wait fallback (the host is demonstrably awake). - apple: `HostRejection` + `.rejected`; the pair sheet and session alerts show the stated reason; connect moves to `ex8`. Completes the cross-client half of the hunks that rode along in 12148243 (client.rs / trust.rs / punktfunk1.rs) — main did not build without this. Validated: workspace clippy -D warnings + full test suite green on .21 (EXIT=0, 309 host / 148 core suites); macOS core 147+c_abi green; swift build green; Android Kotlin + native crate green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 09:58:43 +02:00
enricobuehlerandClaude Fable 5	3ba19f28a2	feat(apple): the gamepad UI comes to tvOS - focus-driven, with real session controls ... The console UI now runs on tvOS through the NATIVE focus engine: carousel cards and settings rows are focusable Buttons (Siri Remote and pads both navigate; imperative scrollTo replaces the drop-prone scrollPosition binding), while iOS/macOS keep the 60 Hz poll untouched - on tvOS it carries only what focus has no concept of: X/Y screen actions and left/right value adjust with the poll's dominant-axis feel (onMoveCommand proved input-source-dependent: keyboard intercepted, pad dpad not -> double steps). Text entry uses the system fullscreen keyboard (TVTextEntry); pairing + library present as covers under the launcher; the game library defaults ON; settings values slide a quiet 14 pt in the step's direction. Session controls: controller/remote input routes EXCLUSIVELY through GameController during a stream (GCEventViewController, interaction disabled) - a pad's B no longer doubles as a UIKit menu press that ended sessions mid-game. Deliberate exits only: the cross-client escape chord (hold L1+R1+Start+Select 1.5 s - pf-client-core's contract, now implemented on all Apple platforms) and holding the remote's Back >= 1 s; the start-of-stream banner (now also on tvOS) teaches both. The Siri Remote's touch surface drives the host pointer - press = left click, Play/Pause = right click, release-tail jumps gated so motion stays truly relative. tvOS 26 regressions fixed at the root: the app-wide brand tint rendered every unfocused control as a blank pill (tint dropped on tvOS) and the 17 pt root font shrank the whole platform (29 pt there), plus 10-foot sizing across host cards, the gamepad screens, and the stats HUD (whose misleading "Press Menu" hint is gone). Acknowledgements scrolls by focus-sized chunks and Menu pops instead of suspending; full-width focusSections make the home actions reachable from any column. The presenter defaults to stage-3 glass pacing on tvOS (a 60 Hz panel fed a 60 fps stream is the sticky-FIFO worst case behind the 50 ms display stage) and is pickable from the gamepad settings; HDR capability advertises from AVPlayer.eligibleForHDRPlayback instead of the current mode's EDR headroom, so an SDR home screen no longer hides an HDR TV. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 16:59:01 +02:00
enricobuehlerandClaude Opus 4.8	60121f1ea9	feat(apple): wake-until-up overlay + host edit with MAC prefill ... - HostWaker + WakeOverlay: after sending the Wake-on-LAN packet, wait until the host is really back (resend + mDNS poll, timeout, cancel/retry) before connecting. macOS-only in practice — WoL stays gated off on iOS/tvOS pending the multicast entitlement. - Add/Edit host sheet gains a Wake-on-LAN MAC field, prefilled from the stored MAC or the live mDNS advert; parseMacs validates aa:bb:cc:dd:ee:ff. - Gamepad chrome/home and glass-style polish. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-05 20:05:17 +02:00
enricobuehlerandClaude Fable 5	34fe896ade	feat(apple): gamepad UI v2 — controller settings + add host, aurora, macOS ... Sources reorganized (client: Home/Session/Settings/Stores/Support/Trust; kit: Audio/Connection/Gamepad/Input/Support/Video/Views) with the big files split along the same seams. The gamepad mode is couch-complete, and now on macOS too (the living-room Mac case), not just iOS/iPadOS: - GamepadSettingsView: a console-style, fully controller-navigable settings screen (X from the launcher) — up/down moves focus, left/right steps values (clamped, boundary thud), A cycles/toggles, B closes; the focused row shows a one-line description. Backed by GamepadMenuList, the vertical sibling of GamepadCarousel, and SettingsOptions — the option lists hoisted out of SettingsView statics and shared by the touch, tvOS and gamepad settings. - GamepadAddHostView + GamepadKeyboard: register a host end to end with a pad — field rows open an on-screen controller keyboard (dpad grid, A types, X backspaces, B done); the launcher carousel ends in an Add Host tile, so the dead-end "add one with touch first" empty state is gone. - Launcher polish: contextual hint bar with the pad's real button glyphs, controller name + battery chip, one shared console chrome. - GamepadScreenBackground: an animated aurora (TimelineView-driven drifting blobs in the brand's violet family, breathing radii, slow hue shift, legibility scrim; freezes under Reduce Motion). Pure SwiftUI on purpose — a .metal library only bundles reliably in one of the two build systems (SPM vs the xcodeproj's synced folders) these sources compile under. - macOS port: settings/add-host/library present as sized sheets (a macOS sheet takes its content's IDEAL size, and the GeometryReader-driven screens collapsed to nothing), NSScreen-based mode lists, scroll indicators .never (the "always show scroll bars" setting overrides .hidden), tray scrims so scrolled rows dim under the pinned title/hints, extra title clearance, and a PUNKTFUNK_FORCE_GAMEPAD_UI=1 dev hook — launcher/settings/add-host/keyboard/ library render-verified live on a real Mac + LAN hosts. - GamepadMenuInput: X button support, and (re)start now snapshots held buttons so a controller handoff press never fires twice (the B that closed the keyboard no longer also cancels the screen underneath). - Cleanups: one "Connection failed" alert in ContentView instead of one per home screen; HostDiscovery.advertises/unsaved shared by both home screens. - host: can_encode_444 stub for the non-Linux/Windows host build (the macOS synthetic-source loopback used by the Swift tests). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 11:24:44 +02:00