What the other two applications keep

Every setting on this page belongs to the standalone player. The other two applications keep their own choices in their own files, on the same rule: a setting is a key in a file you can edit, and a menu or a panel is an editor of that file.

The studio persists through a settings.json beside its own data, written by studio/electron/settings.ts. Nothing it shows is kept in browser storage — localStorage, sessionStorage and indexedDB all keep a choice where no file can be edited and no other process can read it, and scripts/check-settings-have-files.mjs is what holds that to being a property rather than a habit.

Key	Values	Default	What it does
playerPath	a path	none	An explicit player binary, tried after the bundled one and before PATH
playerMode	windowed, windowless	windowed	Which sink the player is spawned with; read at spawn
ui.reducedMotion	true, false	false	Stops the studio’s transitions: panels, tabs and dialogs appear at once. Applied the moment the Settings view writes it. The system’s own reduced-motion preference does the same whatever this says

The studio’s Settings view edits the last two and shows the first; a settings.json written by hand before the first launch is read the same way.

The foobar2000 component has no settings and no file, and the one thing it stores host-side is not one. g_cfg_preset is a cfg_string holding the name of the preset that was last on screen, so a session reopens on the look it closed with. That is resume state, not a setting: nothing about it is chosen, an empty value or a name whose file is gone simply means “whatever the roster opens on”, and forgetting it costs a user nothing but the preset they were watching. The same gate holds every cfg_* declaration in that shim to being named here — which is the only way resume state can be told apart from a setting nobody gave a file.

The day the component grows a real setting, it belongs in config.toml beside the player’s, not in foobar’s own store.