Not exactly preferences, but in the server software that I take part in developing at work, the system configuration in several cases works like this: If there is a new setting, it displays that during a migration and asks for a value or whether to accept a default. If the default of a setting has changed, it displays that during a migration and asks which value to use from now on. Untouched settings are not prompted for again, only during the first installation there is a prompt for all settings.
Note that this is a terminal-based procedure, no GUI. A straight-forward translation into modal dialog boxes would certainly be annoying.
Am Di., 5. Sept. 2023 um 11:32 Uhr schrieb Tim Rowledge tim@rowledge.org:
On 2023-09-04, at 1:22 AM, Marcel Taeumel via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
I would suggest that we should only save preferences that are changed from the defaults, rather than the current 'save everything including several copies of some kitchen sinks I found lying around'.
When carrying over those saved preferences between Squeak releases, those original defaults might have changed. Thus, a complete export seems to make more sense... as it will be more robust?
Hmm. Well for that case I'd suggest a) save all those prefs b) tag ones changed by the user
Then when loading, compare and list a) the ones changed in-system b) the ones changed by the user
Offer a simple way to accept them to build a new set for that release/version.
I wonder how other systems handle this? If you have a file of settings in *nix-land it would typically just have the settings you change, I think. If the system gets updated to have different defaults I think you just have to work it out. Are there any interesting examples of doing thins stuff that people like?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ESBD: Erase System and Burn Documentation