Settingsをアプリへ組み込む

自分のスキーマを埋め込んだSettingsを，アプリ本体とは別の実行ファイルとして配布します。起動時には，編集対象の設定ファイルの絶対パスを渡すと，配置に左右されず使えます。最小例は使い始める，作成方法はビルドを参照してください。

単一インスタンス制約

同じ設定ファイルに対して開けるSettingsは1プロセスです。同じパスで二重起動すると，後から起動したプロセスは終了します。設定ファイルが異なれば，複数のウィンドウを開けます。

既定のconfig.tomlパス

引数を省略した場合の探索は，次のとおりです。

OS・形態	引数省略時の探索
macOSの.app内	実行ファイルがContents/MacOS/にあれば，Contents/Resources/config.toml
Windows・Linux	実行ファイルの隣にconfig.tomlが存在すれば，そのファイル
上記でパスが決まらない開発用起動	ビルド元のSettingsリポジトリにあるdemo/config.toml

設定ファイルは，起動する前に実在するTOMLファイルとして用意します。引数を渡した場合も，存在しないファイルを自動で初期化する方式ではありません。

アプリに同梱する場合，利用者が書き込める設定保存先を本体側で決め，そのパスを渡してください。デモの既定パスは，そのまま製品のユーザー設定の保存先にするための推奨値ではありません。

macOSの.appへの同梱

MyApp.app/Contents/MacOS/
├── MyApp
└── settings

let settings = std::env::current_exe()?.parent().unwrap().join("settings");
std::process::Command::new(settings).arg(config_path).spawn()?;

この例のconfig_pathは，本体側で用意した設定ファイルのパスです。同梱したSettingsも含めて，アプリの署名・配布手順に組み込みます。

Windows

本体とsettings.exeまたは配布名のSettings.exeを同じフォルダーに置き，本体から実行ファイルと設定のパスを指定します。引数を省略すると，隣に存在するconfig.tomlが使われます。

Linux

本体とSettingsの配置を決め，本体からその実行ファイルと設定のパスを指定します。引数を省略すると，隣に存在するconfig.tomlが使われます。

保存と本体への反映

Settingsは指定したTOMLの読み書きを行います。本体への通知や，そのアプリ固有の再読み込み処理は呼び出し側で用意します。

• Settingsを起動したまま変更を反映したい場合は，本体が設定ファイルを監視します。
• Settingsを閉じてから反映する場合は，子プロセスの終了を待って本体が読み直します。

macOSでの自動保存と，Windows・Linuxでの保存バーの使い分けはスキーマの保存モードを参照してください。

Cargo workspaceへの組み込み

Settingsリポジトリには，GUIとsettings-schemaの2つのクレートがあります。SettingsをGit submoduleなどでソースとして取り込み，親側のworkspace構成に合わせて統合するか，独立したビルドとして呼び出します。別プロセスとして使うため，親アプリがRust製である必要はありません。

独自のschema.tomlは親アプリ側で管理し，ビルド時にSETTINGS_SCHEMAまたはSCHEMAで指定します。just binaryでは，指定がなければSettingsリポジトリの1階層上のschema.tomlを使います。詳しくはスキーマの指定を参照してください。