pharo icon indicating copy to clipboard operation
pharo copied to clipboard

Loading settings from a file does not handle default values the way I would expect

Open belaroesener opened this issue 5 months ago • 6 comments

Problem Description

Settings can not be reset to their default value by loading them from a settings file. This creates problematic behavior in different workflows relying on the settings file mechanism, like synchronizing settings between two images or restoring settings to their previous values after trying out changes to the settings.

Problem Reproduction

This reproduction is the simplest case of "misbehavior" and illustrates the mismatch between my expectation and the actual behavior. I will use Code Browsing > Quality Assistant > Criticize final dot in method body (CFD) as an example setting, because it is a toggle rule with a constant default value of true, i.e. it is a very simple kind of setting.

  1. Open a SettingBrowser and check that CFD is on (which is the default)
  2. Store settings
  3. Set CFD to off
  4. Load settings (either in the same, or in another image)
  5. => CFD remains off

As opposed to this, the following works as I would expect:

  1. Set CFD to off
  2. Store settings
  3. Set CFD to on
  4. Load settings
  5. => CFD is set to off

The above behavior is a problem if I want to try out a few settings and then change them back to their previous values using the settings file mechanism. It is also a problem if I want to use the same settings in multiple images, using a settings file to synchronize all changes between the images.

Expected Behavior

When I store the settings of an image, I expect that loading them again restores them completely. (Both when (re)loading the settings in the same image at a later point in time, as well as when loading them into a second image.) In other words, I expect that loading a settings file (re)sets the settings to the same values they were when I stored the them.

Explanation

When the settings are stored, only the settings that have a value different from their default value are actually written to the settings file. When these settings are loaded, the settings in the file are used to set the corresponding settings in the image. But the absence of a setting from the settings file does not affect the corresponding setting in the image. This is a problem, because if a setting does not occur in the settings file, it had its default value when the settings file was created. The loading process should reflect this by ensuring that a setting in the image, that was not stored in the settings file, has its default value after loading the settings file.

Solution

When loading a settings file we can infer that all settings not in the settings file had their default value in the image that created the file. Therefore we can reset each setting that was not mentioned in the settings file, to its default value (if it has one).

belaroesener avatar Sep 17 '25 13:09 belaroesener

Note that besides the button ‘Store Settings’ for storing all settings, there is a context menu item ‘Save to disk’ for saving just an individual setting. Personally, I only use the latter. When getting an image from another computer, such as our Jenkins server, in which some settings have been changed, I would not expect those to get set back to the default value at start-up (through #startUp: and #resumeSystemSettings for SystemSettingsPersistence).

Rinzwind avatar Sep 25 '25 21:09 Rinzwind

Thanks for the comment

Note that besides the button ‘Store Settings’ for storing all settings, there is a context menu item ‘Save to disk’ for saving just an individual setting. Personally, I only use the latter.

This relies on the same code and exhibits the same behaviour, i.e. settings can not be set to their default value via loading from a file.

When getting an image from another computer, such as our Jenkins server, in which some settings have been changed, I would not expect those to get set back to the default value at start-up (through #startUp: and #resumeSystemSettings for SystemSettingsPersistence).

This is a good point. But the settings in such an image do get superseded by any settings in the settings file that don't have a default value, isn't that just as (un)expected?


I still think the behaviour I illustrated above is confusing and should be changed in some way. It's not apparent in the UI whether a setting has a default value or not, yet when I change a setting back to its default, it suddenly won't take effect in other images when loading the settings from a file.

I would be happy to receive and implement suggestions for better solutions.

belaroesener avatar Oct 08 '25 12:10 belaroesener

May you have provide a "setSettingValueFromFile" so that they get changed.

I do not understand why loading a stored setting does not change the setting value. It looks strange to me. Now I understand kris scenario too. So probably we need both. At least to me loading settings should set their values based on the file contents.

Ducasse avatar Oct 08 '25 18:10 Ducasse

BTW thanks for your report and intention to improve Pharo. This is great!

Ducasse avatar Oct 08 '25 18:10 Ducasse

But the settings in such an image do get superseded by any settings in the settings file that don't have a default value, isn't that just as (un)expected?

It’s as expected, or at least is to me, as I used ‘Save to disk’ on the few settings for which I want to always use a particular value. So far that has always been a value other than the default, except in issue #16797 in which I did want to save the value which was then incoherently the default. While the menu item is enabled for a setting set to the default, selecting it doesn’t actually save the setting. I would suggest to change that to always save the setting. I would not apply the same change to the button ‘Store Settings’ as that, taking #resumeSystemSettings into account, would seem more impactful for those used to its current behavior.

Rinzwind avatar Oct 19 '25 10:10 Rinzwind

I do not understand why loading a stored setting does not change the setting value. It looks strange to me. Now I understand kris scenario too. So probably we need both. At least to me loading settings should set their values based on the file contents.

Settings are not stored if they have their default value, therefore loading a setting file can not reset a setting to the default value. So the problem is not that stored settings are not loaded properly, but that some settings will not be stored.

It’s as expected, or at least is to me, as I used ‘Save to disk’ on the few settings for which I want to always use a particular value. So far that has always been a value other than the default, except in issue #16797 in which I did want to save the value which was then incoherently the default. While the menu item is enabled for a setting set to the default, selecting it doesn’t actually save the setting. I would suggest to change that to always save the setting. I would not apply the same change to the button ‘Store Settings’ as that, taking #resumeSystemSettings into account, would seem more impactful for those used to its current behavior.

I agree with your argument to keep the previous behaviour of the Store Settings Button.

I propose the following changes:

  1. ~Enable saving of settings with default value when saving single settings.~ (Not possible. Not worth the effort.)
  2. Adding a Reset to Defaults button, which resets all settings to their default value if possible. (Using this button and the Store Settings button in sequence would enable the behaviour I would like to have.)
  3. Add documentation for both the default values behaviour and the #resumeSystemSettings behaviour. (I think both behaviours are worth mentioning to beginners like me)

I will work on 1 and 2 and open a PR for them, but I would like some guidance on 3, as I don't know what the appropriate place would be to add a short comment about these.

belaroesener avatar Nov 05 '25 14:11 belaroesener