[squeak-dev] The Inbox: System-ct.1119.mcz

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sat Nov 2 02:05:17 UTC 2019


Hi Marcel,


> you are proposing an interface to temporarily override specific preferences with an automatic restoring to their previous values after a work block.


I think that's not actually a new interface, it's just a convenience method for #setPreference:toValue:during:. It should only complement #setPreferences: which was my actual proposal.


Do you think we should prefer the pair-based implementation (#setPreferencesFrom:) over the association-based proposal? If yes, I would like to complement it with a #setPreferencesFrom:during: implementation, just to align it with #setPreference:toValue: and #setPreference:toValue:during:.


> Also, the "key" for pragma preferences (i.e., "Model>>#useColorfulWindows")  is kind of a private implementation detail, I suppose. I would rather not expose it that way.

Thank you for the pointer! I have often used this in test code and always ignored the fact that this reveals the private storage format of the Preferences class.
However, I find it quite useful to control all preferences from one central place. Should we maybe introduce an extra protocol for accessing pragma preferences?
Preferences setPreferenceFrom: Model key: #useColorfulWindows toValue: #false.
It feels so inconsistent to mix calls to Preferences with calls to separate classes ...

I would definitively favor something like
Preferences
    setPreferencesFrom: #(
        (balloonHelpEnabled false)
        (Model useColorfulWindows false)
        (TextEditor autoEnclose true))
    during: [self perfomTest]
-over-
Preferences setPreference: #balloonHelpEnabled toValue: false during: [
    lastModel := Model useColorfulWindows.
    enclose := TextEditor enclose.
    Model useColorfulWindows: false.
    TextEditor autoEnclose: true.
    [self performTest] ensure: [
        Model useColorfulWindows: lastModel.
        TextEditor autoEnclose: enclose]]!

(I'm a big fan of the execution around pattern :-))

Regarding your proposal #restoreAfter: - wouldn't this be an O(n) approach instead of an O(1) approach?


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 29. Oktober 2019 14:51:32
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] The Inbox: System-ct.1119.mcz

Hi Christoph,

you are proposing an interface to temporarily override specific preferences with an automatic restoring to their previous values after a work block. The examples you pointed to in Flaps and PreferenceWizardMorph would both not benefit from such a mechanism.

You are also proposing an interface to set preferences from a list of associations. Yes, this is kind of duplicate to the already existing #setPreferencesFrom:, which expects a list of pairs . Also, the "key" for pragma preferences (i.e., "Model>>#useColorfulWindows")  is kind of a private implementation detail, I suppose. I would rather not expose it that way.

Squeak's current mix of pragma preferences and "old-style" preferences is not optimal. I think we have the policy to add new preferences always as pragma preferencs.

I think that it is a good idea to add a mechanism to conveniently restore preferences after a work block. What about this kind of interface:

Preferences restoreAfter: [
   Browser showClassIcons: true.
   Preferences setFlag: #menuWithIcons toValue: switch.
   self doSomeThing].

It would be easy to just copy all the preferences and restore them after the workblock.

Still, I would rather not encourage such a trick in regular application code. Yet, it would be easy to hunt down and review all senders of #restoreAfter: from time to time ... Just my two cents. :-)

Best,
Marcel

Am 29.10.2019 12:47:55 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:

Well, you could use it in methods such as Flaps class >> makeNavigatorFlapResembleGoldenBar or PreferenceWizardMorph >> toggleToolAndMenuIcons as well, but there are few of these senders outside of test methods.


However, I just discovered a possible duplicate, Preferences >> #setPreferencesFrom:. Do you think that's a problem? I think the old nested array style is less convenient compared to the use of associations, and there is no "during" version ...


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 29. Oktober 2019 10:59:30
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] The Inbox: System-ct.1119.mcz

Hmm.... this sounds like it is meant to be used in tests only. Or are there other scenarios? Putting this in regular application code might yield confusing effects or hacky code.

So, what about putting this into an *SUnit extension category?

Best,
Marcel

Am 26.10.2019 22:01:13 schrieb commits at source.squeak.org <commits at source.squeak.org>:

A new version of System was added to project The Inbox:
http://source.squeak.org/inbox/System-ct.1119.mcz

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

Name: System-ct.1119
Author: ct
Time: 26 October 2019, 10:00:59.779469 pm
UUID: dc499ab1-dfe1-064c-a997-271a591d4b18
Ancestors: System-mt.1116

Adds convenience methods to change multiple preferences

Usage example:

Preferences
setPreferences: {
#(UIManager >> #openToolsAttachedToMouseCursor) join asSymbol -> false.
#(Model >> #useColorfulWindows) join asSymbol -> false }
during: [self notify: 'Carpe Squeak!']

=============== Diff against System-mt.1116 ===============

Item was added:
+ ----- Method: Preferences class>>setPreferences: (in category 'get/set') -----
+ setPreferences: associations
+
+ associations associationsDo: [:association |
+ self setPreference: association key toValue: association value].!

Item was added:
+ ----- Method: Preferences class>>setPreferences:during: (in category 'get/set') -----
+ setPreferences: associations during: aBlock
+ "Changes the given values for the duration of aBlock"
+
+ | values previousValues |
+ values := associations as: Dictionary.
+ previousValues := values associations collect: [:association |
+ association key -> (self valueOfFlag: association key)].
+ self setPreferences: values.
+ ^ aBlock ensure: [
+ self setPreferences: previousValues]!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191102/8de7ebb5/attachment.html>


More information about the Squeak-dev mailing list