[squeak-dev] Default preferences
Christoph.Thiede at student.hpi.uni-potsdam.de
Sat May 21 16:59:41 UTC 2022
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. :-)
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Samstag, 21. Mai 2022 04:07:30
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.
Am 20.05.2022 06:55:47 schrieb Thiede, Christoph <christoph.thiede at 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. :-)
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
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).
mail at jaromir.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev