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:

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