Fwd: [squeak-dev] [ANN] Preference pragmas

> As some of us are unregistered, I thought it could be of interest ;)
>
>
> ---------- Forwarded message ----------
> From: Andreas Raab <[hidden email]>
> Date: 2009/3/4
> Subject: [squeak-dev] [ANN] Preference pragmas
> To: The general-purpose Squeak developers list
> <[hidden email]>
>
>
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> 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 <[hidden email]>
>> Date: 2009/3/4
>> Subject: [squeak-dev] [ANN] Preference pragmas
>> To: The general-purpose Squeak developers list
>> <[hidden email]>
>>
>>
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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

>
> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> <PrefListener2-alain_plantec.
> 5.mcz>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 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.

> 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!!!
>  

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>