Watch config file changes and apply without restart

[GeneralD]

Motivation

Currently config is loaded once at startup via ConfigKey.liveValue. Any changes to config.toml require restarting the daemon to take effect, making it tedious to iterate on styling.

Proposal

• Watch ~/.config/backdrop/config.toml for changes using DispatchSource.makeFileSystemObjectSource or FSEvents
• On change, reload and re-resolve config
• Apply new config to the running overlay (text styles, colors, ripple, artwork, etc.)
• Show error notification if the updated config is invalid (keep previous config)

Relevant Code

• Sources/BackdropConfig/AppConfig.swift:318-322 — ConfigKey.liveValue is a static let, loaded once
• Sources/BackdropApp/OverlayWindow.swift — reads config at init only
• Sources/BackdropUI/Views/*.swift — read config via @Dependency(\.config)

[GeneralD]

Config changes are applied via backdrop restart. File watching adds complexity without sufficient benefit — static let liveValue prevents in-process config reload.

[GeneralD]

の結果、wontfix としてクローズします。

1. issue の陳腐化
本文が参照する Sources/BackdropConfig/AppConfig.swift・Sources/BackdropApp/OverlayWindow.swift、製品名 backdrop、~/.config/backdrop/config.toml、backdrop restart は、その後の lyra へのと VIPER + Clean Architecture 全面リファクタで現存しません。

2. 現アーキテクチャでのコスト
設定は ConfigUseCaseImpl の private lazy var cachedAppStyle = repository.loadAppStyle() により起動時に一度だけロード・キャッシュされ、DI も static let liveValue の単一インスタンスです。各 Interactor / Presenter は start() 時に設定をキャプチャして @Published へ流すため、hot-reload には config の publisher 化と VIPER チェーン全体(Header / Lyrics / Wallpaper / Ripple / App Presenter)へのという横断的なリアクティブ化が必要です。

3. 過去の実装試行
実際に一度 hot-reload の実装を試みた経緯がありますが、状態の二重管理やライフサイクルが絡みが多く実用に至りませんでした。複雑度に見合う便益が薄いという issue 上の既存コメントの指摘ともします。

4. 代替手段
設定変更は lyra の再起動(brew services restart lyra、または lyra stop && lyra start)でできます。スタイル調整の反復はこれで足ります。

将来、設定エディタ GUI 連動など別の動機でリアクティブ化する場合は、現アーキを前提に scope し直した新しい issue でします。

[GeneralD]

現アーキ（VIPER + Clean Architecture 後）で config hot-reload が実際どう実現できるか、実コードに当てて調査しました。結論から言うと「配線の大半は既にするが、3つの欠けたピースを足す必要がある」状態です。

0. まず本文の Relevant Code は陳腐化しています

この issue を立てた時点のモジュール名（BackdropConfig / BackdropApp / BackdropUI / ConfigKey.liveValue）は全てリネーム・済みで、現在は存在しません。ファイルパスも ~/.config/backdrop/config.toml → ~/.config/lyra/config.toml に変わっています。以下が現行コードへのマップです。

旧 → 現 コード対応表

旧本文の	現行の対応箇所
BackdropConfig/AppConfig.swift ConfigKey.liveValue（一回ロード）	Sources/ConfigUseCase/ConfigUseCaseImpl.swift の private lazy var cachedAppStyle
BackdropApp/OverlayWindow.swift（init時のみ読む）	Sources/Presenters/**（start() でキャプチャ）+ Sources/Views/Overlay/AppWindow.swift
BackdropUI/Views/*.swift（@Dependency(\.config)）	Views は Presenter の @Published を @ObservedObject で。config 直読みは
~/.config/backdrop/config.toml	~/.config/lyra/config.toml（ConfigDataSourceImpl.findConfigFile()）

1. フリーズの根源は箇所だけ

が再読込されない直接原因は、UseCase の 一回限りの lazy キャッシュです。

// Sources/ConfigUseCase/ConfigUseCaseImpl.swift
private lazy var cachedAppStyle: AppStyle = repository.loadAppStyle()
public var appStyle: AppStyle { cachedAppStyle }   // 凍結した値を返すだけ

初回アクセス時に loadAppStyle() を一度だけ実行し、以降は固定。reload / reset が存在しません。ここが唯一のボトルネックです。

2. 朗報 — Interactor 層はすでにライブ読み

Interactor の config 系プロパティは全て毎回 configService.appStyle を読み直す計算プロパティになっています。

TrackInteractorImpl.swift:100/104/108/145   decodeEffect / text / artwork / ai
WallpaperInteractorImpl.swift:16/20/43       mode / items / ripple
ScreenInteractorImpl.swift:21/26             screen / screenDebounce

つまり §1 の cachedAppStyle の凍結さえ解ければ、Interactor 層は的に新 config を拾います。ここに改修は要りません。これが「配線の大半は既にある」のです。

3. ファイルプリミティブは皆無

ソースに FSEvents / kqueue / DispatchSource.makeFileSystemObjectSource は一つも存在しません（grep でゼロ）。DispatchSource の用途はシグナル処理のみ（App/SignalTerminationHandler.swift）。機構は新規に作る必要があります。

4. 最後の壁 — Presenter は start() でキャプチャして固定

Presenter は start() で config を stored property に焼き付け、以後は再適用しません。再スタイルメソッドがしないのが本丸です。

// Sources/Presenters/Track/HeaderPresenter.swift:43-68
public func start() {
    let style = interactor.textLayout
    titleStyle = style.title        // 一度だけ代入
    artistStyle = style.artist
    titleColor = style.title.color  // titleColor/artistColor は @Published
    ...
}

titleColor / artistColor は @Published なので再代入すれば View にしますが、titleStyle 等は非 @Published。そしてそもそも再適用を駆動する導線が無いのがです。

5. 最小案（既存パターンの再利用）

3ピースで組めます。いずれも例があります。

1. File watcher を — DispatchSource.makeFileSystemObjectSource で config.toml を監視。エディタの atomic save（rename）にするため、親ディレクトリ監視 or watch を貼り直す方式。骨格は AppPresenter の vacant ポーリング Task（AppPresenter.swift:73-83、source → subject を stop() で cancel）と同型で書けます。

2. cachedAppStyle を可変化 — lazy var を捨て、reload() で repository.loadAppStyle() を再実行 → 新 AppStyle を保持 → を publish。不正な config の時は回値を維持（本文の要件どおり）。Interactor は §2 のとおり追従。

3. Presenter に再適用導線を — watcher → Interactor 経由 → 各 Presenter の restyle(_:) 的メソッド → 既存の idempotent な apply（AppWindow.apply 等）で差分反映。#265 で実証済みの「冪等 apply」がそのまま再適用シンクになります。

6. 正直なコストと段階

このは過去に試して不安定だった経緯があり wontfix で閉じられていました。現アーキでは Interactor 層がライブ読みなのは追い風ですが、難所は Presenter 再適用導線を全 Presenter（Header / Lyrics / Wallpaper / Ripple / App）に通すこと、特に中の DecodeEffect アニメや AVPlayer 再構築（wallpaper 差し替え）の扱いが設計判断ポイントです。

現実的には段階を推奨します。

• Phase 1（軽い）: テキストのスタイル・色だけ hot-reload。Presenter の @Published 再代入で済む。effort 小、体感メリット大（スタイル試行錯誤の主用途を即カバー）。
• Phase 2（重い）: wallpaper / screen / ripple など、再コストの高い対象へ拡張。

まず Phase 1 を切り出した小さな から始めるのが安全だと考えます。