[squeak-dev] Default preferences

karl ramberg karlramberg at gmail.com
Wed Jun 1 05:34:20 UTC 2022


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 at 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 at 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 at 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 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. :-)
>>
>>
>> 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
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220601/f76fa023/attachment-0001.html>


More information about the Squeak-dev mailing list