Embedding

Settings (v0.2.2)

Single-instance constraint

At most one Settings process may have a given config.toml open at a time. If you launch a second instance pointed at the same config file path, the newly launched process exits immediately. Multiple windows can be open concurrently as long as they point at different config file paths.

Default config.toml path

When launched without an argument, the default path that gets loaded depends on the platform and packaging form.

OS / form	Default path
macOS (bundled in .app)	Contents/Resources/config.toml (a resource inside the bundle)
Windows	config.toml in the same directory as Settings.exe
Linux	config.toml in the same directory as the executable binary

Bundling into a macOS .app

MyApp.app/Contents/MacOS/
├── MyApp
└── settings    # or Settings — match it to your bundle name

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

Windows

Place the executable and Settings.exe in the same directory, and have your installer place both. When bundled this way, the config.toml placed next to Settings.exe is used as the default when the argument is omitted.

Linux

The config.toml placed in the same directory as the binary is used as the default when the argument is omitted.

Embedding in a Cargo workspace

[workspace]
members = [".", "settings-schema", "settings"]  # match the structure to your parent app

Bring in settings as a Git submodule or a path dependency. Manage the schema in the parent repository and point to it at build time via the SETTINGS_SCHEMA environment variable, or the Makefile's SCHEMA variable. For details on how the schema path is specified at build time, including the order of precedence, see Building.