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
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
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@jaromir.net
From: Thiede, Christophmailto:Christoph.Thiede@student.hpi.uni-potsdam.de Sent: Friday, May 20, 2022 15:16 To: Squeak Devmailto:squeak-dev@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@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
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:
- 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.
- 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
On 2022-05-20, at 6:16 AM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
my proposal would be that we set all Preferences' defaultValues to their value during the release building -
Exactly; the release builder should be not just setting the settings but setting the settings for the settings ;-)
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Foolproof operation: All parameters are hard coded.
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
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
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:
- 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.
- 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
At least a warning to transcript stream that the preference is missing from current preferences would be helpful.
A pop up warning would probably mess with a lot of file in code.
Best, Karl
On Wed, 1 Jun 2022 at 00:14, Chris Muller asqueaker@gmail.com wrote:
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:
- 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.
- 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
squeak-dev@lists.squeakfoundation.org