Problem

Picard writes user configuration and volatile UI state into a single INI file. In Picard.ini the [persist] section holds window geometry, splitter positions, column layouts, etc., which are all rewritten on nearly every quit. Additionally it also holds [setting], which changes only when the user deliberately edits options.

This makes the config file impossible to share across machines, because the two categories have opposite lifetimes.

Consequences

• Config sync is impractical.
  • Users syncing Picard.ini via Syncthing/Dropbox/git get conflicts on every quit.
• Backups are noisy.
  • The existing autobackup_directory feature captures a file whose diffs are dominated by window positions.
• Version control is unusable for users who want to track their tagging setup.

Feasibility

The section abstraction already exists and is cleanly separated. In picard/config.py, Config.__initialize constructs four independent sections over one store:

self.application: ConfigSection = ConfigSection(self, 'application')
self.profiles: ConfigSection = ConfigSection(self, 'profiles')
self.setting: SettingConfigSection = SettingConfigSection(self, 'setting')
self.persist: ConfigSection = ConfigSection(self, 'persist')

ConfigSection._init stores the config as self._qt_config and reaches the backing store only through it. Notably _persist is a plain ConfigSection, so it has no interaction with profile override resolution.

Allowing persist to be constructed against a second QSettings instance therefore appears to require no changes at call sites. I have not attempted the refactor, so there might be changes needed in some places that are not clear from just reading through the relevant code.

Proposed behaviour

• Back [persist] with its own file, e.g. Picard-persist.ini, in the same directory as the main config.
• Make the location overridable, consistent with PICARD_CONFIG_DIR PICARD_CACHE_DIR and PICARD_PLUGIN_DIR. A PICARD_PERSIST_FILE variable and/or a --persist-file CLI option would match established convention.
• Preserve the current single-file layout as the default if back-compability is a concern, with the split opt-in.

Related

A secondary motivation is declarative configuration management (NixOS/Home Manager,  dotfile managers), where the config file is generated and read-only.