Skip to content

[Latent Audit] P2 · Medium · The "Show mini-player controls" preference is never read by anything — the toggle does nothing #82

Description

@latent-variable

Severity: Medium · dead_code · confidence high
Location: app/Sources/Yap/Prefs.swift:110

Impact: Settings ▸ General offers a "Show mini-player controls" switch that has no effect on the app. The menu's transport row (play/pause, stop, "Read selection") is rendered unconditionally, so a user who turns the switch off sees no change and no way to get it back on. This has been shipped dead in every release since the initial scaffold, and it keeps a stored UserDefaults key, an ObservableObject property and a didSet write alive for a feature that has never existed.

Evidence: Prefs.swift:110 declares the setting: @Published var showMiniPlayer: Bool { didSet { d.set(showMiniPlayer, forKey: "showMiniPlayer") } }, and Prefs.swift:175 loads it: showMiniPlayer = d.object(forKey: "showMiniPlayer") as? Bool ?? true. The ONLY other occurrence in the whole checkout is the control itself — app/Sources/Yap/Views/SettingsView.swift:119: Toggle("Show mini-player controls", isOn: $prefs.showMiniPlayer). Verified with grep -rn "showMiniPlayer" . (excluding .git) run from the repo root: three hits, all of them the declaration, the load line, and the Toggle. Ruled out the ways it could still be live: d is private let d = UserDefaults.standard, so no other file can read the key by string; there is no @AppStorage("showMiniPlayer") anywhere (the only @AppStorage in the app is "menuTab", MenuContent.swift:13); app/Package.swift declares a single Yap executable target with no test target and no second consumer, so nothing outside this repo imports it; Carbon/Services dispatch is by selector (readWithYap: in Info.plist), not by preference name. And the thing it would plausibly gate is unconditional — MenuContent.swift:96 includes transport in voiceSection with no condition, and MenuContent.swift:190 defines it. git log -S showMiniPlayer --oneline returns exactly one commit, 4c277bb ("Phase 0: scaffold Parley"), which added all three references at once (app/Sources/Parley/Prefs.swift:73, :93, app/Sources/Parley/Views/SettingsView.swift:41); no later commit ever added or removed a reader, so a consumer never existed rather than one being deleted.

Recommendation: Delete it: remove the showMiniPlayer property (Prefs.swift:110) and its initializer line (Prefs.swift:175), and remove the Toggle at SettingsView.swift:119. Nothing else changes, because nothing reads it. Wiring it up instead (gating transport in MenuContent.voiceSection) is more code for a control that has never actually worked; the smaller system is the better one here. If product wants the toggle to exist, then it must gate the transport row — but that is a feature, not a fix, and it should not be done under the cover of this cleanup.

Cross-validated by: codex — Verified Prefs.swift declares and loads showMiniPlayer, SettingsView is its only other repository reference, and MenuContent renders transport unconditionally. I also checked the repository and listed sibling workspaces for string/key references, config or build references, dynamic or reflection-style uses, deliberate keep comments, and external consumers; Package.swift has only one executable target.

Filed automatically by latent-git-agents (auditor, agent: pi). Dedupe token: latent-audit-fp-1899139a81508f22

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Scheduled, not urgentcleanupRemovable code: dead paths, unused deps, tests that cannot fail

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions