[Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas
As some of us are unregistered, I thought it could be of interest ;) ---------- Forwarded message ---------- From: Andreas Raab <andreas.raab@gmx.de> Date: 2009/3/4 Subject: [squeak-dev] [ANN] Preference pragmas To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org> Folks - I wanted to make the property whether to show individual processes in MessageTally a preference and couldn't recall any of the three gazillion methods to create one ;-) So I decided enough is enough and added the ability to register a preference via Pragma. In other words, you specify two class side accessors (using MessageTally as example): showProcesses     "Indicates whether to show each process separately or cumulatively."     <preference: 'Show Processes in MessageTally'         category: 'debug'         balloonHelp: 'If enabled, each profiled process is shown individually in MessageTally'         type: #Boolean>     ^ShowProcesses showProcesses: aBool     "Indicates whether to show each process separately or cumulatively."     ShowProcesses := aBool. and then register the preference in the class initialization method via: initialize     "MessageTally initialize"     "By default, show each process separately"     ShowProcesses := true.     "Register preferences"     Preferences addPreferencesFor: self. The nice thing about this scheme is that the preference is local to the code where it's used and that there are no more generated accessors which mess up Monticello packages etc. What could probably be improved is the self-registration; I left it that way for now since I don't know how expensive it would be to scan all classes for new preferences when one opens a preference browser. There is also an example class PreferenceExample that illustrates the different types of preferences (textual, numeric, color, boolean) you can use. To install, just execute the following from Squeak 3.10.2:  Installer mantis fixBug: 7306. Enjoy!  - Andreas -- Cédrick
Thanks this is strange that exactly the same week where we talk about that and where we discuss about announcements, such topics got interesting from some other people. We are probably not that wrong. ;) Thanks cedric keep us informed. Stef On Mar 4, 2009, at 11:26 AM, Cédrick Béler wrote:
As some of us are unregistered, I thought it could be of interest ;)
---------- Forwarded message ---------- From: Andreas Raab <andreas.raab@gmx.de> Date: 2009/3/4 Subject: [squeak-dev] [ANN] Preference pragmas To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Folks -
I wanted to make the property whether to show individual processes in MessageTally a preference and couldn't recall any of the three gazillion methods to create one ;-) So I decided enough is enough and added the ability to register a preference via Pragma. In other words, you specify two class side accessors (using MessageTally as example):
showProcesses "Indicates whether to show each process separately or cumulatively." <preference: 'Show Processes in MessageTally' category: 'debug' balloonHelp: 'If enabled, each profiled process is shown individually in MessageTally' type: #Boolean> ^ShowProcesses
showProcesses: aBool "Indicates whether to show each process separately or cumulatively." ShowProcesses := aBool.
and then register the preference in the class initialization method via:
initialize "MessageTally initialize" "By default, show each process separately" ShowProcesses := true. "Register preferences" Preferences addPreferencesFor: self.
The nice thing about this scheme is that the preference is local to the code where it's used and that there are no more generated accessors which mess up Monticello packages etc. What could probably be improved is the self-registration; I left it that way for now since I don't know how expensive it would be to scan all classes for new preferences when one opens a preference browser. There is also an example class PreferenceExample that illustrates the different types of preferences (textual, numeric, color, boolean) you can use.
To install, just execute the following from Squeak 3.10.2:
Installer mantis fixBug: 7306.
Enjoy! - Andreas
-- Cédrick
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/3/4 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Thanks this is strange that exactly the same week where we talk about that and where we discuss about announcements, such topics got interesting from some other people. We are probably not that wrong. ;) Thanks cedric keep us informed.
no problems, I can do that ;) you see that's exactly why I find Pharo forks as the right decision... First, it frees you (and this is huge)... Second people indirectly accepts/pick ideas/participate to what's discussed... :) So now, in a certain way, we have "le beurre et l'argent du beurre" ;) Cheers
Stef
On Mar 4, 2009, at 11:26 AM, Cédrick Béler wrote:
As some of us are unregistered, I thought it could be of interest ;)
---------- Forwarded message ---------- From: Andreas Raab <andreas.raab@gmx.de> Date: 2009/3/4 Subject: [squeak-dev] [ANN] Preference pragmas To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Folks -
I wanted to make the property whether to show individual processes in MessageTally a preference and couldn't recall any of the three gazillion methods to create one ;-) So I decided enough is enough and added the ability to register a preference via Pragma. In other words, you specify two class side accessors (using MessageTally as example):
showProcesses     "Indicates whether to show each process separately or cumulatively."     <preference: 'Show Processes in MessageTally'         category: 'debug'         balloonHelp: 'If enabled, each profiled process is shown individually in MessageTally'         type: #Boolean>     ^ShowProcesses
showProcesses: aBool     "Indicates whether to show each process separately or cumulatively."     ShowProcesses := aBool.
and then register the preference in the class initialization method via:
initialize     "MessageTally initialize"     "By default, show each process separately"     ShowProcesses := true.     "Register preferences"     Preferences addPreferencesFor: self.
The nice thing about this scheme is that the preference is local to the code where it's used and that there are no more generated accessors which mess up Monticello packages etc. What could probably be improved is the self-registration; I left it that way for now since I don't know how expensive it would be to scan all classes for new preferences when one opens a preference browser. There is also an example class PreferenceExample that illustrates the different types of preferences (textual, numeric, color, boolean) you can use.
To install, just execute the following from Squeak 3.10.2:
 Installer mantis fixBug: 7306.
Enjoy! Â - Andreas
-- Cédrick
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Cédrick
Hi all, Here is a Preference engine based on pragma. please, check it and tell me if it is ok or not. If you prefer squeak version, no problem but tell me that I stop working on this. The set of system preferences constitutes a tree of preferences. The model for the tree is implemented by the PreferenceNode hierarchy. (see PrefCore2). This is the only mandatory part. The tree can be visualized with a PreferenceTree UI built on top of PrefCore2 (see PrefTool2 and snapshot). Examples of preference declaration are given in PrefProvider2. in order to open the tree: PreferenceTree open. Thank to Gary for its help. cheers alain Stéphane Ducasse a écrit :
Thanks this is strange that exactly the same week where we talk about that and where we discuss about announcements, such topics got interesting from some other people. We are probably not that wrong. ;) Thanks cedric keep us informed.
Stef
On Mar 4, 2009, at 11:26 AM, Cédrick Béler wrote:
As some of us are unregistered, I thought it could be of interest ;)
---------- Forwarded message ---------- From: Andreas Raab <andreas.raab@gmx.de> Date: 2009/3/4 Subject: [squeak-dev] [ANN] Preference pragmas To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Folks -
I wanted to make the property whether to show individual processes in MessageTally a preference and couldn't recall any of the three gazillion methods to create one ;-) So I decided enough is enough and added the ability to register a preference via Pragma. In other words, you specify two class side accessors (using MessageTally as example):
showProcesses "Indicates whether to show each process separately or cumulatively." <preference: 'Show Processes in MessageTally' category: 'debug' balloonHelp: 'If enabled, each profiled process is shown individually in MessageTally' type: #Boolean> ^ShowProcesses
showProcesses: aBool "Indicates whether to show each process separately or cumulatively." ShowProcesses := aBool.
and then register the preference in the class initialization method via:
initialize "MessageTally initialize" "By default, show each process separately" ShowProcesses := true. "Register preferences" Preferences addPreferencesFor: self.
The nice thing about this scheme is that the preference is local to the code where it's used and that there are no more generated accessors which mess up Monticello packages etc. What could probably be improved is the self-registration; I left it that way for now since I don't know how expensive it would be to scan all classes for new preferences when one opens a preference browser. There is also an example class PreferenceExample that illustrates the different types of preferences (textual, numeric, color, boolean) you can use.
To install, just execute the following from Squeak 3.10.2:
Installer mantis fixBug: 7306.
Enjoy! - Andreas
-- Cédrick
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Argh, I forgot to say that, for one preference, only one method must be written. example for gradientButtonLook: UIPreferences>>gradientButtonLook <preference> ^ GradientButtonLook ifNil: [GradientButtonLook := PreferenceValue name: 'Gradient look for buttons' description: 'Gradient look for buttons' parent: #uiPreferenceNode type: #Boolean default: false] You can note the use of a minimal pragma form. We finally prefered objects over flat pragma declaration. This allow the use of a composite pattern for the tree and for one-to-many preference declaration. As an example: UIPreferences>>themePreference <preference> ^ ThemePreference ifNil: [ThemePreference := MultiplePreferenceValue name: 'UITheme' description: 'The theme to use for UI look and feel' parent: #uiPreferenceNode type: #UITheme default: UIThemeWatery2 values: { FixedPreferenceValue name: 'Standard Squeak' description: 'Standard Squeak style' type: #UITheme value: UIThemeStandardSqueak. FixedPreferenceValue name: 'Watery 2' description: 'Similar to a nice OS' type: #UITheme value: UIThemeWatery2}] You can also have range: FreeTypePreferences>>glyphContrast <preference> ^ GlyphContrast ifNil: [GlyphContrast := RangePreferenceValue name: 'Glyph contrast' description: 'Change the contrast level for glyphs. This is an integer between 1 and 100. (the default value is 50)' parent: #freeTypePreferenceNode type: #Integer default: 50 range: (1 to: 100)] Multiple and range preference value are not so easy to describe well if we only make use of literals (pragma constraint). Other point, how to use preferences. Example of a preference reading and changing: gradientLook := UIPreferences gradientButtonLook value. UIPreferences gradientButtonLook value: true. Last but not least point is that it provides system level preference change notification. to see it in action, load PrefListener2 package (the version I have attached to this mail, previous version was not ok) Cheers alain Alain Plantec a écrit :
Hi all, Here is a Preference engine based on pragma. please, check it and tell me if it is ok or not. If you prefer squeak version, no problem but tell me that I stop working on this.
The set of system preferences constitutes a tree of preferences. The model for the tree is implemented by the PreferenceNode hierarchy. (see PrefCore2). This is the only mandatory part. The tree can be visualized with a PreferenceTree UI built on top of PrefCore2 (see PrefTool2 and snapshot). Examples of preference declaration are given in PrefProvider2. in order to open the tree: PreferenceTree open. Thank to Gary for its help.
cheers alain
------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi alain I guessed right :) So this is good to me. Stef On Mar 4, 2009, at 5:54 PM, Alain Plantec wrote:
Argh, I forgot to say that, for one preference, only one method must be written. example for gradientButtonLook: UIPreferences>>gradientButtonLook <preference> ^ GradientButtonLook ifNil: [GradientButtonLook := PreferenceValue name: 'Gradient look for buttons' description: 'Gradient look for buttons' parent: #uiPreferenceNode type: #Boolean default: false]
You can note the use of a minimal pragma form. We finally prefered objects over flat pragma declaration. This allow the use of a composite pattern for the tree and for one- to-many preference declaration. As an example: UIPreferences>>themePreference <preference> ^ ThemePreference ifNil: [ThemePreference := MultiplePreferenceValue name: 'UITheme' description: 'The theme to use for UI look and feel' parent: #uiPreferenceNode type: #UITheme default: UIThemeWatery2 values: { FixedPreferenceValue name: 'Standard Squeak' description: 'Standard Squeak style' type: #UITheme value: UIThemeStandardSqueak. FixedPreferenceValue name: 'Watery 2' description: 'Similar to a nice OS' type: #UITheme value: UIThemeWatery2}]
You can also have range: FreeTypePreferences>>glyphContrast <preference> ^ GlyphContrast ifNil: [GlyphContrast := RangePreferenceValue name: 'Glyph contrast' description: 'Change the contrast level for glyphs. This is an integer between 1 and 100. (the default value is 50)' parent: #freeTypePreferenceNode type: #Integer default: 50 range: (1 to: 100)]
Multiple and range preference value are not so easy to describe well if we only make use of literals (pragma constraint).
Other point, how to use preferences. Example of a preference reading and changing: gradientLook := UIPreferences gradientButtonLook value. UIPreferences gradientButtonLook value: true.
Last but not least point is that it provides system level preference change notification. to see it in action, load PrefListener2 package (the version I have attached to this mail, previous version was not ok)
Cheers alain
Alain Plantec a écrit :
Hi all, Here is a Preference engine based on pragma. please, check it and tell me if it is ok or not. If you prefer squeak version, no problem but tell me that I stop working on this.
The set of system preferences constitutes a tree of preferences. The model for the tree is implemented by the PreferenceNode hierarchy. (see PrefCore2). This is the only mandatory part. The tree can be visualized with a PreferenceTree UI built on top of PrefCore2 (see PrefTool2 and snapshot). Examples of preference declaration are given in PrefProvider2. in order to open the tree: PreferenceTree open. Thank to Gary for its help.
cheers alain
------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
<PrefListener2-alain_plantec. 5.mcz>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi alain
Hi all, Here is a Preference engine based on pragma. please, check it and tell me if it is ok or not. If you prefer squeak version,
this will be difficult :) I reread all the emails you exchanged with gary and igor. What is a parentNode in AbtsractPreferenceValue? This is when you have a composite preference? I understood when reading the code of PrefProvider2
no problem but tell me that I stop working on this.
The set of system preferences constitutes a tree of preferences. The model for the tree is implemented by the PreferenceNode hierarchy. (see PrefCore2). This is the only mandatory part. The tree can be visualized with a PreferenceTree UI built on top of PrefCore2 (see PrefTool2 and snapshot). Examples of preference declaration are given in PrefProvider2. in order to open the tree: PreferenceTree open
I have two naive questions: - I imagine that we will be able to reuse the Preference browser and that we do not have to rebuild one? because the pragma preference collector could be put there? Or is it better to rewrite everything? - second I was wondering why you only use <preference> and not <preference:zork:> like in andreas solution? Gary mentioned that some objects can be more complex than mere literal. I was wondering if for the interface it would not be better to have cascaded selector instead of methods with multiple argument. PreferenceNode name: 'HTTP proxy' description: 'http proxy name and port' parent: #networkPreferenceNode vs PreferenceNode new name: 'HTTP proxy' ; description: 'http proxy name and port' ; parent: #networkPreferenceNode So can I summarize your approach as follow? - packages can defined locally their preferences (by construction this will be better since people will have to think about preferences value as their stuff. not the one of preference so this will help the flow to be local --- good. - preferences are not centralized anymore (youpi) - tools can register to get notified when preferences changes - preferences can be complex objects - preferences are structured in preferences tree. Sounds cool to me. I will let the other give their point of view. I'm leaving on vacation now. Stef PS: test should be "self test" PrefChangeListener new inspect. UIPreferences gradientButtonLook value: UIPreferences gradientButtonLook value not. UIPreferences gradientButtonLook value: UIPreferences gradientButtonLook value not. UIPreferences gradientButtonLook value: UIPreferences gradientButtonLook value not.
Stéphane Ducasse a écrit :
I reread all the emails you exchanged with gary and igor. What is a parentNode in AbtsractPreferenceValue? This is when you have a composite preference? yes I understood when reading the code of PrefProvider2
no problem but tell me that I stop working on this.
The set of system preferences constitutes a tree of preferences. The model for the tree is implemented by the PreferenceNode hierarchy. (see PrefCore2). This is the only mandatory part. The tree can be visualized with a PreferenceTree UI built on top of PrefCore2 (see PrefTool2 and snapshot). Examples of preference declaration are given in PrefProvider2. in order to open the tree: PreferenceTree open
I have two naive questions: - I imagine that we will be able to reuse the Preference browser and that we do not have to rebuild one? because the pragma preference collector could be put there? Or is it better to rewrite everything? I guess we can reuse some parts.
- second I was wondering why you only use <preference> and not <preference:zork:> like in andreas solution? Gary mentioned that some objects can be more complex than mere literal. and he convinced me not to use <preference:zork:> for two main reasons -Only one model for preference in the image (no need to retrieve the pragma or to store them in a second model) -<preference:zork:> is flat, it allow on literals as parameters, so it is very difficult to describe composites
I was wondering if for the interface it would not be better to have cascaded selector instead of methods with multiple argument.
PreferenceNode name: 'HTTP proxy' description: 'http proxy name and port' parent: #networkPreferenceNode vs PreferenceNode new name: 'HTTP proxy' ; description: 'http proxy name and port' ; parent: #networkPreferenceNode ok for me.
So can I summarize your approach as follow?
- packages can defined locally their preferences (by construction this will be better since people will have to think about preferences value as their stuff. not the one of preference so this will help the flow to be local --- good. - preferences are not centralized anymore (youpi) - tools can register to get notified when preferences changes - preferences can be complex objects - preferences are structured in preferences tree. exactly
Sounds cool to me. I will let the other give their point of view. I'm leaving on vacation now.
Stef
PS: test should be
"self test" PrefChangeListener new inspect. UIPreferences gradientButtonLook value: UIPreferences gradientButtonLook value not. UIPreferences gradientButtonLook value: UIPreferences gradientButtonLook value not. UIPreferences gradientButtonLook value: UIPreferences gradientButtonLook value not. yes, this is the version you have in PrefListener.5.mcz
alain
So let us know when we integrate it :) Stef
Stéphane Ducasse a écrit :
I reread all the emails you exchanged with gary and igor. What is a parentNode in AbtsractPreferenceValue? This is when you have a composite preference? yes I understood when reading the code of PrefProvider2
no problem but tell me that I stop working on this.
The set of system preferences constitutes a tree of preferences. The model for the tree is implemented by the PreferenceNode hierarchy. (see PrefCore2). This is the only mandatory part. The tree can be visualized with a PreferenceTree UI built on top of PrefCore2 (see PrefTool2 and snapshot). Examples of preference declaration are given in PrefProvider2. in order to open the tree: PreferenceTree open
I have two naive questions: - I imagine that we will be able to reuse the Preference browser and that we do not have to rebuild one? because the pragma preference collector could be put there? Or is it better to rewrite everything? I guess we can reuse some parts.
- second I was wondering why you only use <preference> and not <preference:zork:> like in andreas solution? Gary mentioned that some objects can be more complex than mere literal. and he convinced me not to use <preference:zork:> for two main reasons -Only one model for preference in the image (no need to retrieve the pragma or to store them in a second model) -<preference:zork:> is flat, it allow on literals as parameters, so it is very difficult to describe composites
I was wondering if for the interface it would not be better to have cascaded selector instead of methods with multiple argument.
PreferenceNode name: 'HTTP proxy' description: 'http proxy name and port' parent: #networkPreferenceNode vs PreferenceNode new name: 'HTTP proxy' ; description: 'http proxy name and port' ; parent: #networkPreferenceNode ok for me.
So can I summarize your approach as follow?
- packages can defined locally their preferences (by construction this will be better since people will have to think about preferences value as their stuff. not the one of preference so this will help the flow to be local --- good. - preferences are not centralized anymore (youpi) - tools can register to get notified when preferences changes - preferences can be complex objects - preferences are structured in preferences tree. exactly
Sounds cool to me. I will let the other give their point of view. I'm leaving on vacation now.
Stef
PS: test should be
"self test" PrefChangeListener new inspect. UIPreferences gradientButtonLook value: UIPreferences gradientButtonLook value not. UIPreferences gradientButtonLook value: UIPreferences gradientButtonLook value not. UIPreferences gradientButtonLook value: UIPreferences gradientButtonLook value not. yes, this is the version you have in PrefListener.5.mcz
alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Alain Plantec wrote:
Hi all, Here is a Preference engine based on pragma. please, check it and tell me if it is ok or not. If you prefer squeak version, no problem but tell me that I stop working on this.
Well, I guess that is exactly what we don't want (that you stop working on it). Just because someone magically pretends to have come up with the same idea (and some others "coincidentally") without giving you credit for it does not mean that your work is suddenly obsolete. Please keep up the good work for Pharo!!! Michael
Michael Rueger a écrit :
Alain Plantec wrote:
Hi all, Here is a Preference engine based on pragma. please, check it and tell me if it is ok or not. If you prefer squeak version, no problem but tell me that I stop working on this.
Well, I guess that is exactly what we don't want (that you stop working on it).
Just because someone magically pretends to have come up with the same idea (and some others "coincidentally") without giving you credit for it does not mean that your work is suddenly obsolete. Please keep up the good work for Pharo!!!
thank for your support Michael. but if I remember well, the idea is from Lukas, and Gary help me also. Cheers alain
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Just because someone magically pretends to have come up with the same idea (and some others "coincidentally") without giving you credit for it does not mean that your work is suddenly obsolete. Please keep up the good work for Pharo!!!
thank for your support Michael. but if I remember well, the idea is from Lukas, and Gary help me also.
:) Stef ]
+200 I think that Pharo is becoming cool and aggregating good energy and some people are afraid of it to succeed because of its good energy. And indeed such coincidence look suspicious to me. I only see great and cool stuff happening: no mvc, no etoy, lot of fixes,... and more soon Stef On Mar 4, 2009, at 8:24 PM, Michael Rueger wrote:
Alain Plantec wrote:
Hi all, Here is a Preference engine based on pragma. please, check it and tell me if it is ok or not. If you prefer squeak version, no problem but tell me that I stop working on this.
Well, I guess that is exactly what we don't want (that you stop working on it).
Just because someone magically pretends to have come up with the same idea (and some others "coincidentally") without giving you credit for it does not mean that your work is suddenly obsolete. Please keep up the good work for Pharo!!!
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Alain Plantec -
Cédrick Béler -
Michael Rueger -
Stéphane Ducasse