The Inbox: System-ct.1119.mcz
Locked
 
|
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]! |
Re: 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
|
Re: The Inbox: System-ct.1119.mcz
|
|
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 <[hidden email]> 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
Carpe Squeak!
|
Re: 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
|
Re: The Inbox: System-ct.1119.mcz
|
|
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 <[hidden email]> 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
Carpe Squeak!
|
Re: The Inbox: System-ct.1119.mcz
|
|
> Regarding your proposal #restoreAfter: - wouldn't this be an O(n) approach instead of an O(1) approach? That depends on how it will be implemented. ;-) More imporantly, the user does not have to use special format for the pragma preferences. Just the usual code with a sandbox around it. That's convenient! > I would definitively favor something like ... (Model useColorfulWindows false) ... -1 too much disguise of a pragma preference. But that's just an opinion. :-) Also, preferences values can be complex objects such as colors or fill styles. > It feels so inconsistent to mix calls to Preferences with calls to separate classes ... I know. Then again, it's just some global state where the usage should be minimized anyway. :-D Best, Marcel
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |