Alright, please see the attached changeset, everyone. It does not eliminate configuration drift completely, but at least eliminates the first cause for that.

Best, Christoph

=============== Summary ===============

Change Set: resetPreferences Date: 20 May 2022 Author: Christoph Thiede

Adds missing clean-ups for preferences:

1. Add Preferences resetDefaultValues and send it from ReleaseBuilders after #setPreferences to bring the default values of non-pragma preferences in sync with the fresh values. See: http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-January/218191.h... 2. Merge Preferences cleanUp and Preferences cleanUp: to ensure that both are executed. See SmalltalkImage>>#cleanUp:except:. 3. Clean up project preferences during Project clean-up.

Note that we have still two sources of truth for default preference values (the intrinsic #defaultValue/pragma getter and the extrinsic database ReleaseBuilder>>setPreferences). See http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-January/218191.h... for more information.

=============== Diff ===============

PragmaPreference>>resetDefaultValue {initialization} · ct 5/20/2022 18:03 + resetDefaultValue + "No-op. Pragma preferences do not have default values."

Preference>>resetDefaultValue {initialization} · ct 5/20/2022 18:03 + resetDefaultValue + + self defaultValue: self preferenceValue.

Preferences class>>cleanUp {class initialization} · mt 1/24/2019 14:12 (removed) - cleanUp - - "Synchronize the cache for pragma preferences. Note that the actual preferences values are stored in class variables. So, no such value gets lost if we remove all such preferences from that cache." - self removeAllPreferencesSuchThat: [:preference | - preference isPragmaPreference]. - SystemNavigation default allSelectorsAndMethodsDo: [:behavior :selector :method | - method pragmas do: [:pragma | - self addPragmaPreference: pragma]]. - - "Remove obsolete (non-pragma) preferences." - self removeObsolete.

Preferences class>>cleanUp: {initialization} · ct 5/20/2022 18:01 (changed) cleanUp: aggressive

+ self cleanUpPragmaPreferences. + + "Remove obsolete (non-pragma) preferences." + self removeObsolete. + aggressive ifTrue: [ self class organization categories select: [:ea | ea beginsWith: '*autogenerated'] thenDo: [:ea | self class removeCategory: ea]].

Preferences class>>cleanUpPragmaPreferences {initialization} · ct 5/20/2022 17:15 + cleanUpPragmaPreferences + "Synchronize the cache for pragma preferences. Note that the actual preferences values are stored in class variables. So, no such value gets lost if we remove all such preferences from that cache." + + self removeAllPreferencesSuchThat: [:preference | + preference isPragmaPreference]. + SystemNavigation default allSelectorsAndMethodsDo: [:behavior :selector :method | + method pragmas do: [:pragma | + self addPragmaPreference: pragma]].

Preferences class>>resetDefaultValues {initialization} · ct 5/20/2022 18:02 + resetDefaultValues + + self allPreferences do: [:preference | + preference resetDefaultValue].

Project class>>cleanUp: {class initialization} · ct 5/20/2022 18:13 (changed) cleanUp: agressive "Remove all projects but only when cleaning aggressively"

agressive ifTrue:[ self removeAllButCurrent. - self current resourceManager reset]. + self current resourceManager reset]. + + self allSubInstancesDo: [:project | + project projectPreferenceFlagDictionary removeAll]. + self allSubInstancesDo: [:project | + project initializeProjectPreferences].

ReleaseBuilder class>>clearPreferenceCaches {scripts} · ct 5/20/2022 18:06 + clearPreferenceCaches + + Preferences resetDefaultValues.

ReleaseBuilder class>>prepareEnvironment {preparing} · ct 5/20/2022 18:05 (changed) prepareEnvironment "Prepare everything that should be done for a new image build. Clear caches, passwords, etc." | balloon | self clearCaches; configureProjects; configureTools; setPreferences; + clearPreferenceCaches; configureDesktop. balloon := self getBalloonForm. "Get now because later the file might be missing." DeferredTask := [ self openWelcomeWorkspacesWith: balloon. PreferenceWizardMorph open]. "If you save-and-quit the image after calling #prepareEnvironment, ensure that the next image startup will be fast." Project current world doOneCycle. Display platformScaleFactor: 1.0.

ReleaseBuilderSqueakland class>>intermediatePrepareForUsers {scripts} · ct 5/20/2022 18:06 (changed) intermediatePrepareForUsers "self intermediatePrepareForUsers" Project cleanUpEtoysGarbage. Smalltalk zapAllOtherProjects. Project cleanUpEtoysGarbage. ReleaseBuilder clearCaches. ObjectScanner new. "clear ObjectScanner's class pool" ExternalSettings registerClient: ServerDirectory. Project cleanUpEtoysGarbage. ReleaseBuilderSqueakland configureDesktop. ReleaseBuilderSqueakland setPreferences. + ReleaseBuilderSqueakland clearPreferenceCaches. Model useColorfulWindows: true.

ReleaseBuilderSqueakland class>>setPreferences {scripts} · ct 5/20/2022 18:05 (changed) setPreferences

super setPreferences. [ "Reset all preferences to their default value but ensure that all control and alt keys stay duplicated." Preferences cambridge. + self flag: #suspicious. "ct: This does not set the preferences to their default values, but reconfigures the default values based on their current values... If this is intended, update the comment and use Preferences resetDefaultValues." Preferences allPreferences do: [:each | each defaultValue: each preferenceValue]. Preferences enable: #duplicateAllControlAndAltKeys. ] valueSupplyingAnswer: true.

Preferences disable: #alternativeWindowBoxesLook; enable: #magicHalos; enable: #mouseOverHalos; enable: #showAdvancedNavigatorButtons; disable: #honorDesktopCmdKeys; enable: #unlimitedPaintArea; enable: #fastDragWindowForMorphic; enable: #noviceMode; disable: #generalizedYellowButtonMenu; disable: #signProjectFiles; enable: #alwaysHideHScrollbar; enable: #alwaysShowVScrollbar. "For the menu button." ScrollBar scrollBarsWithoutMenuButton: false. ScrollBar scrollBarsWithoutArrowButtons: false.

"Rounded corners." Morph preferredCornerRadius: 8. PluggableButtonMorph roundedButtonCorners: true. DialogWindow roundedDialogCorners: true. SystemWindow roundedWindowCorners: true. ScrollBar roundedScrollBarLook: true.

Cursor useBiggerCursors: true. TrashCanMorph slideDismissalsToTrash: true; preserveTrash: true. SugarNavigatorBar showHideButton: false; showSugarNavigator: true. Preferences disable: #showAdvancedNavigatorButtons. TileMorph usePopUpArrows: true. Morph indicateKeyboardFocus: false. "Ignore warnings." Deprecation showDeprecationWarnings: false. Preferences disable: #warnIfChangesFileReadOnly; disable: #warnIfNoChangesFile; disable: #warnIfNoSourcesFile.

--- Sent from Squeak Inbox Talk

On 2022-05-20T14:36:00+00:00, mail@jaromir.net wrote:

Hi Christoph, all,

...

my proposal would be that we set all Preferences' defaultValues to their value during the release building

Yes, that feels intuitive and I like the defaults the image comes with; I personally only need to make like 4 changes in the wizard and would appreciate to be able to get back to that default set.

Thanks,

--

Jaromír Matas

+420 777 492 777 mail at jaromir.net

From: Thiede, Christoph<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de> Sent: Friday, May 20, 2022 15:16 To: Squeak Dev<mailto:squeak-dev at lists.squeakfoundation.org> Subject: Re: [squeak-dev] Default preferences

Hi Jaromir, hi all,

thanks for finding this! This is insane. I suppose that no one in the last years has ever pressed this "default" button and thus this inconsistency was never found.

We seem to have two sources of truth here:

1. The default value of each preference:

1a. For pragma preferences, this is encoded in the getter of the preference (i.e., Model class>>#useColorfulWindows falls back to true).

1b. For old-style preferences, this is the defaultValue variable of the preference instance (this is not encoded anywhere, just historic instances that have been handed down since years or decades via the release images like the Olympic torch). See Preferences preferenceAt: #fastDragWindowForMorphic for example.

2. The default values encoded in the ReleaseBuilder (or actually, the ReleaseBuilders, since this thing is even subclassed), see #setPreferences. For instance, here #useColorfulWindows is set to false.

This is really crazy. I feel like traveling ten years back in time after clicking that button. I don't know how we should solve the two sources of truth problem, but my proposal would be that we set all Preferences' defaultValues to their value during the release building - how do you think about that? Would some others agree with that? If yes, I can implement & upload that.

...

A theme is not a 'preference', despite the Preference Wizard sets it, right? (slightly confusing but ok)

Yes. The Preference Wizard does not display all preferences, but it also provides access to some other options. For instance, the preference browser also does not have logic for installing recommended packages. :-)

Best,

Christoph

Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jaromir Matas <mail at jaromir.net> Gesendet: Freitag, 20. Mai 2022 10:03:23 An: Squeak Dev Betreff: [squeak-dev] Default preferences

Hi All, A quick question: What are the 'default preferences'?

I thought they were the ones the fresh image comes with but when you open a Preference Browser and hit the 'default' button you get another set of preferences (round buttons, colorful windows etc.) ? is this a bug? Is there a way to get back to the preferences the image comes with?

A theme is not a 'preference', despite the Preference Wizard sets it, right? (slightly confusing but ok) (BTW the Community Dark theme is awesome! Even italic comments :) Using it all the time)

Also, if I check the 'English' tick-box in Extras -> Language, the flaps show (that must be a bug).

Best,

--

Jaromír Matas

mail at jaromir.net

my proposal would be that we set all Preferences' defaultValues to their value during the release building

This would be kind of dangerous and difficult to manage regarding a proper base image for the CI (i.e., the bundles). I think we should rather uncover what is not yet set in ReleaseBuilder class >> #setPreferences and fill in the gaps. That's makes it explicit. For those values, we can surely set the defaults for old-style preferences.

Best, Marcel Am 20.05.2022 06:55:47 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Jaromir, hi all,

thanks for finding this! This is insane. I suppose that no one in the last years has ever pressed this "default" button and thus this inconsistency was never found.

We seem to have two sources of truth here: 1. The default value of each preference:   1a. For pragma preferences, this is encoded in the getter of the preference (i.e., Model class>>#useColorfulWindows falls back to true).   1b. For old-style preferences, this is the defaultValue variable of the preference instance (this is not encoded anywhere, just historic instances that have been handed down since years or decades via the release images like the Olympic torch). See Preferences preferenceAt: #fastDragWindowForMorphic for example. 2. The default values encoded in the ReleaseBuilder (or actually, the ReleaseBuilders, since this thing is even subclassed), see #setPreferences. For instance, here #useColorfulWindows is set to false.

This is really crazy. I feel like traveling ten years back in time after clicking that button. I don't know how we should solve the two sources of truth problem, but my proposal would be that we set all Preferences' defaultValues to their value during the release building - how do you think about that? Would some others agree with that? If yes, I can implement & upload that.

A theme is not a 'preference', despite the Preference Wizard sets it, right? (slightly confusing but ok)

Yes. The Preference Wizard does not display all preferences, but it also provides access to some other options. For instance, the preference browser also does not have logic for installing recommended packages. :-)

Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jaromir Matas mail@jaromir.net Gesendet: Freitag, 20. Mai 2022 10:03:23 An: Squeak Dev Betreff: [squeak-dev] Default preferences   Hi All, A quick question: What are the 'default preferences'?   I thought they were the ones the fresh image comes with but when you open a Preference Browser and hit the 'default' button you get another set of preferences (round buttons, colorful windows etc.) – is this a bug? Is there a way to get back to the preferences the image comes with?   A theme is not a 'preference', despite the Preference Wizard sets it, right? (slightly confusing but ok) (BTW the Community Dark theme is awesome! Even italic comments :) Using it all the time)   Also, if I check the 'English' tick-box in Extras -> Language, the flaps show (that must be a bug).   Best, -- Jaromír Matas mail@jaromir.net

Thank you Christoph!

I found some old configuration code of mine that was setting some preferences that no longer exist, and was shocked that it simply ignored my request instead of complaining! This is a dreadful bug still present in trunk to this day, check it out!

Preferences enable: #oogalaboogala "works!"

Soo bad! It not only makes it really hard to know there's a problem at all, but also how to find and fix it (e.g., what was the preference renamed to?)! These kinds of silent failures are the 2nd-worst kinds of bugs one can have (the 1st-worst are silent corruptors of your data).

Anything to make this more defined and/or brittle is a welcome improvement.

Thanks, Chris

On Sat, May 21, 2022 at 11:59 AM Thiede, Christoph < Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:

Hi Marcel,

but this would still leave a chance that we miss any historic states. My proposal is a bit more radical in this regard, but it makes sure that we have a consistent and deterministic set of preference values ... What problems would you concretely see with that? The only visible effect should be that in a freshly generated image, the default button in the preference browser does not change any preferences to ancient defaults. :-)

Best,

Christoph

*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Samstag, 21. Mai 2022 04:07:30 *An:* squeak-dev *Betreff:* Re: [squeak-dev] Default preferences

...

my proposal would be that we set all Preferences' defaultValues to

their value during the release building

This would be kind of dangerous and difficult to manage regarding a proper base image for the CI (i.e., the bundles). I think we should rather uncover what is not yet set in ReleaseBuilder class >> #setPreferences and fill in the gaps. That's makes it explicit. For those values, we can surely set the defaults for old-style preferences.

Best, Marcel

Am 20.05.2022 06:55:47 schrieb Thiede, Christoph < christoph.thiede@student.hpi.uni-potsdam.de>:

Hi Jaromir, hi all,

thanks for finding this! This is insane. I suppose that no one in the last years has ever pressed this "default" button and thus this inconsistency was never found.

We seem to have two sources of truth here:

1. The default value of each preference:

1a. For pragma preferences, this is encoded in the getter of the preference (i.e., Model class>>#useColorfulWindows falls back to true).

1b. For old-style preferences, this is the defaultValue variable of the preference instance (this is not encoded anywhere, just historic instances that have been handed down since years or decades via the release images like the Olympic torch). See Preferences preferenceAt: #fastDragWindowForMorphic for example.

2. The default values encoded in the ReleaseBuilder (or actually, the

ReleaseBuilders, since this thing is even subclassed), see #setPreferences. For instance, here #useColorfulWindows is set to false.

This is really crazy. I feel like traveling ten years back in time after clicking that button. I don't know how we should solve the two sources of truth problem, but my proposal would be that we set all Preferences' defaultValues to their value during the release building - how do you think about that? Would some others agree with that? If yes, I can implement & upload that.

...

A theme is not a 'preference', despite the Preference Wizard sets it,

right? (slightly confusing but ok)

Yes. The Preference Wizard does not display all preferences, but it also provides access to some other options. For instance, the preference browser also does not have logic for installing recommended packages. :-)

Best,

Christoph

---

*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jaromir Matas mail@jaromir.net *Gesendet:* Freitag, 20. Mai 2022 10:03:23 *An:* Squeak Dev *Betreff:* [squeak-dev] Default preferences

Hi All,

A quick question: What are the 'default preferences'?

I thought they were the ones the fresh image comes with but when you open a Preference Browser and hit the 'default' button you get another set of preferences (round buttons, colorful windows etc.) – is this a bug? Is there a way to get back to the preferences the image comes with?

A theme is not a 'preference', despite the Preference Wizard sets it, right? (slightly confusing but ok) (BTW the Community Dark theme is awesome! Even italic comments :) Using it all the time)

Also, if I check the 'English' tick-box in Extras -> Language, the flaps show (that must be a bug).

Best,

--

*Jaromír Matas*

mail@jaromir.net