Preference refactoring again

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Preference refactoring again

Alain Plantec-4
Hi all,

joined Zoo package is a attempt to translate in code what we discussed  
here before about preference refactoring.

The framework is made of 3 classes: PreferenceCollector,
PreferenceDefinition and PreferenceValue.
In Zoo there are also 2 classes for testing: PrefProvider and
PrefChangeListener.
PrefProvider class declares some preferences and PrefChangeListener is
here to test preference change notification.

PrefChangeListener>>initialize
    super initialize.
    PreferenceCollector whenChanged: #gradientButtonLook inClass:
PrefProvider notify: self using: #gradientButtonLookIsNow: .
    PreferenceCollector whenChanged: #gradientButtonLook inClass:
PrefProvider notify: self using: #gradientLook:

PrefChangeListener class>>test
    "self test"
    PrefChangeListener new inspect.
    PrefProvider  gradientButtonLook: PrefProvider gradientButtonLook
value not.
    PrefProvider  gradientButtonLook: PrefProvider gradientButtonLook
value not.
    PrefProvider  gradientButtonLook: PrefProvider gradientButtonLook
value not.


 From PreferenceCollector comment:
--------------------------------------
A PreferenceCollector automatically collects all preferences.
A preference is represented by a PreferenceDefinition.
All  PreferenceDefinition are stored in the preferences instance variable.

Instance Variables
    preferences:        OrderedCollection of PreferenceDefinition

preferences
    - contains all PreferenceDefinition which are automatically built
from pragma found in preference getters


ADDING A PREFERENCE
PreferenceCollector makes use of the SystemChangeNotifier in order to
automate the adding, the removing and the updating of preferences.
See #PreferenceCollector>>event:  to see how preferences update is
implemented.

Editing a new method with a preference pragma or inserting a preference
pragma in an existing method are
the two ways for preference definition adding.
The only way to remove a preference definition is to remove the
corresponding method.

Example of a "blackAndWhite" preference.
Methods below are defined by the preference provider APreferencePrivider
class.
Note that the value stored in BlackAndWhite class variable is an
instance of PreferenceValue.
In this example, the default value is directly given with the pragma:
-------------
APreferencePrivider class>>blackAndWhite
    <preference: 'Use black and white' type: #Boolean set:
#blackAndWhite: defaultValue: false description: 'Use black and white'>
    ^ BlackAndWhite
        ifNil: [BlackAndWhite := PreferenceValue value: false location:
self selector: #blackAndWhite]

APreferencePrivider class>>blackAndWhite: aBoolean
        self blackAndWhite value: aBoolean
-------------

If a default value can't be specified in the pragma, another way
consists in using a selector which
represents the message to send to the class in order to get the default
value:

-------------
APreferencePrivider class>>standardFont
    <preference: 'The default system font' type: #LogicalFont set:
#standardFont: default: #defaultStandardFont description: 'The default
system font'>
    ^ StandardFont
        ifNil: [StandardFont := PreferenceValue value: self
defaultStandardFont location: self selector: #standardFont]

APreferencePrivider class>>standardFont: aFont
    self standardFont value: aFont
   
APreferencePrivider class>>defaultStandardFont
            ^ LogicalFont
                        familyName: 'Arial'
                        fallbackFamilyNames: nil
                        pointSize: 12
                        stretchValue: 5
                        weightValue: 400
                        slantValue: 0
-------------

LISTENING TO A PREFERENCE VALUE CHANGE
Any object can register itself as a preference value change listener.
See #PreferenceCollector class>>whenChanged: inClass:notify:using:.

Each time a preference value is changed, #preference:
inClass:changedWith: is sent to the PreferenceCollector class.

Example of code a listener can implement in order to be notified each
time a gradientButtonLook preference defined by a PrefProvider class is
changed.
In this example, the listener ask to be notified by a send of
#gradientButtonLookIsNow: message.
The argument given to gradientButtonLookIsNow: is the new preference value.
-------------
    ....
    PreferenceCollector whenChanged: #gradientButtonLook inClass:
PrefProvider notify: self using: #gradientButtonLookIsNow:.
    ....
-------------

What do you think ?

cheers
Alain



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Zoo-alain_plantec.10.mcz (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Stéphane Ducasse
sounds cool.
For me the most important aspect is that preferenceCollector (our  
current preference class should be a removable layer on top
of the system that are declaring preference.

Is is correct that

  PreferenceCollector whenChanged: #gradientButtonLook inClass:  
PrefProvider notify: self using: #gradientButtonLookIsNow: .

means that PrefProvider will receive the message
                gradientButtonLookIsNow:

This way we can push preference to the tools and thety do not  have to  
query the information in the Collector at run-time (hence we could  
remove Preference and have a more OO design).

Sorry not to reply earlier (I was breaking yet another wall in our  
"kitchen")

Stef


On Mar 1, 2009, at 10:05 AM, Alain Plantec wrote:

> Hi all,
>
> joined Zoo package is a attempt to translate in code what we  
> discussed  here before about preference refactoring.
>
> The framework is made of 3 classes: PreferenceCollector,  
> PreferenceDefinition and PreferenceValue.
> In Zoo there are also 2 classes for testing: PrefProvider and  
> PrefChangeListener.
> PrefProvider class declares some preferences and PrefChangeListener  
> is here to test preference change notification.
>
> PrefChangeListener>>initialize
>   super initialize.
>   PreferenceCollector whenChanged: #gradientButtonLook inClass:  
> PrefProvider notify: self using: #gradientButtonLookIsNow: .
>   PreferenceCollector whenChanged: #gradientButtonLook inClass:  
> PrefProvider notify: self using: #gradientLook:
>
> PrefChangeListener class>>test
>   "self test"
>   PrefChangeListener new inspect.
>   PrefProvider  gradientButtonLook: PrefProvider gradientButtonLook  
> value not.
>   PrefProvider  gradientButtonLook: PrefProvider gradientButtonLook  
> value not.
>   PrefProvider  gradientButtonLook: PrefProvider gradientButtonLook  
> value not.
>
>
> From PreferenceCollector comment:
> --------------------------------------
> A PreferenceCollector automatically collects all preferences.
> A preference is represented by a PreferenceDefinition.
> All  PreferenceDefinition are stored in the preferences instance  
> variable.
>
> Instance Variables
>   preferences:        OrderedCollection of PreferenceDefinition
>
> preferences
>   - contains all PreferenceDefinition which are automatically built  
> from pragma found in preference getters
>
>
> ADDING A PREFERENCE
> PreferenceCollector makes use of the SystemChangeNotifier in order  
> to automate the adding, the removing and the updating of preferences.
> See #PreferenceCollector>>event:  to see how preferences update is  
> implemented.
>
> Editing a new method with a preference pragma or inserting a  
> preference pragma in an existing method are
> the two ways for preference definition adding.
> The only way to remove a preference definition is to remove the  
> corresponding method.
>
> Example of a "blackAndWhite" preference.
> Methods below are defined by the preference provider  
> APreferencePrivider class.
> Note that the value stored in BlackAndWhite class variable is an  
> instance of PreferenceValue.
> In this example, the default value is directly given with the pragma:
> -------------
> APreferencePrivider class>>blackAndWhite
>   <preference: 'Use black and white' type: #Boolean set:  
> #blackAndWhite: defaultValue: false description: 'Use black and  
> white'>
>   ^ BlackAndWhite
>       ifNil: [BlackAndWhite := PreferenceValue value: false  
> location: self selector: #blackAndWhite]
>
> APreferencePrivider class>>blackAndWhite: aBoolean
>       self blackAndWhite value: aBoolean
> -------------
>
> If a default value can't be specified in the pragma, another way  
> consists in using a selector which
> represents the message to send to the class in order to get the  
> default value:
>
> -------------
> APreferencePrivider class>>standardFont
>   <preference: 'The default system font' type: #LogicalFont set:  
> #standardFont: default: #defaultStandardFont description: 'The  
> default system font'>
>   ^ StandardFont
>       ifNil: [StandardFont := PreferenceValue value: self  
> defaultStandardFont location: self selector: #standardFont]
>
> APreferencePrivider class>>standardFont: aFont
>   self standardFont value: aFont
>  APreferencePrivider class>>defaultStandardFont
>           ^ LogicalFont
>                       familyName: 'Arial'
>                       fallbackFamilyNames: nil
>                       pointSize: 12
>                       stretchValue: 5
>                       weightValue: 400
>                       slantValue: 0
> -------------
>
> LISTENING TO A PREFERENCE VALUE CHANGE
> Any object can register itself as a preference value change listener.
> See #PreferenceCollector class>>whenChanged: inClass:notify:using:.
>
> Each time a preference value is changed, #preference:  
> inClass:changedWith: is sent to the PreferenceCollector class.
>
> Example of code a listener can implement in order to be notified  
> each time a gradientButtonLook preference defined by a PrefProvider  
> class is changed.
> In this example, the listener ask to be notified by a send of  
> #gradientButtonLookIsNow: message.
> The argument given to gradientButtonLookIsNow: is the new preference  
> value.
> -------------
>   ....
>   PreferenceCollector whenChanged: #gradientButtonLook inClass:  
> PrefProvider notify: self using: #gradientButtonLookIsNow:.
>   ....
> -------------
>
> What do you think ?
>
> cheers
> Alain
>
>
> <Zoo-alain_plantec.
> 10.mcz>_______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Alain Plantec-4
Stéphane Ducasse a écrit :

> sounds cool.
> For me the most important aspect is that preferenceCollector (our
> current preference class should be a removable layer on top
> of the system that are declaring preference.
>
> Is is correct that
>
>  PreferenceCollector whenChanged: #gradientButtonLook inClass:
> PrefProvider notify: self using: #gradientButtonLookIsNow: .
>
> means that PrefProvider will receive the message
>         gradientButtonLookIsNow:
no, but see the code below:
-----------
PrefListener>>initialize
    super initialize.
    PreferenceCollector whenChanged: #gradientButtonLook inClass:
PrefProvider notify: self using: #gradientButtonLookIsNow: .
-----------

it means that a PrefListener instance will receive the
#gradientButtonLookIsNow: message each time the preference
#gradientButtonLook defined in class PrefProvider is changed.

PrefListener and PrefProvider represent can  be any class in the system.
So, in order to read a preference value an object get it from the
provider class by message sending,
the provider is a class in a package which defines preferences (no need
for PreferenceCollector to get the preference value).
>
> This way we can push preference to the tools
yes
> and thety do not  have to query the information in the Collector at
> run-time
yes,
Each package have its own preference set in it represented by a set of
methods with pragma.
When such a package is loaded, its preferences are automatically stored
by PreferenceCollector.
When a package is removed, its preferences are automatically removed
from PreferenceCollector.
PreferenceCollector is only here for supporting tools (cool UI ...) and
for change notifications.

> (hence we could remove Preference and have a more OO design).
I guess yes.
>
> Sorry not to reply earlier (I was breaking yet another wall in our
> "kitchen")
bon courage :)

alain

>
> Stef
>
>
> On Mar 1, 2009, at 10:05 AM, Alain Plantec wrote:
>
>> Hi all,
>>
>> joined Zoo package is a attempt to translate in code what we
>> discussed  here before about preference refactoring.
>>
>> The framework is made of 3 classes: PreferenceCollector,
>> PreferenceDefinition and PreferenceValue.
>> In Zoo there are also 2 classes for testing: PrefProvider and
>> PrefChangeListener.
>> PrefProvider class declares some preferences and PrefChangeListener
>> is here to test preference change notification.
>>
>> PrefChangeListener>>initialize
>>   super initialize.
>>   PreferenceCollector whenChanged: #gradientButtonLook inClass:
>> PrefProvider notify: self using: #gradientButtonLookIsNow: .
>>   PreferenceCollector whenChanged: #gradientButtonLook inClass:
>> PrefProvider notify: self using: #gradientLook:
>>
>> PrefChangeListener class>>test
>>   "self test"
>>   PrefChangeListener new inspect.
>>   PrefProvider  gradientButtonLook: PrefProvider gradientButtonLook
>> value not.
>>   PrefProvider  gradientButtonLook: PrefProvider gradientButtonLook
>> value not.
>>   PrefProvider  gradientButtonLook: PrefProvider gradientButtonLook
>> value not.
>>
>>
>> From PreferenceCollector comment:
>> --------------------------------------
>> A PreferenceCollector automatically collects all preferences.
>> A preference is represented by a PreferenceDefinition.
>> All  PreferenceDefinition are stored in the preferences instance
>> variable.
>>
>> Instance Variables
>>   preferences:        OrderedCollection of PreferenceDefinition
>>
>> preferences
>>   - contains all PreferenceDefinition which are automatically built
>> from pragma found in preference getters
>>
>>
>> ADDING A PREFERENCE
>> PreferenceCollector makes use of the SystemChangeNotifier in order to
>> automate the adding, the removing and the updating of preferences.
>> See #PreferenceCollector>>event:  to see how preferences update is
>> implemented.
>>
>> Editing a new method with a preference pragma or inserting a
>> preference pragma in an existing method are
>> the two ways for preference definition adding.
>> The only way to remove a preference definition is to remove the
>> corresponding method.
>>
>> Example of a "blackAndWhite" preference.
>> Methods below are defined by the preference provider
>> APreferencePrivider class.
>> Note that the value stored in BlackAndWhite class variable is an
>> instance of PreferenceValue.
>> In this example, the default value is directly given with the pragma:
>> -------------
>> APreferencePrivider class>>blackAndWhite
>>   <preference: 'Use black and white' type: #Boolean set:
>> #blackAndWhite: defaultValue: false description: 'Use black and white'>
>>   ^ BlackAndWhite
>>       ifNil: [BlackAndWhite := PreferenceValue value: false location:
>> self selector: #blackAndWhite]
>>
>> APreferencePrivider class>>blackAndWhite: aBoolean
>>       self blackAndWhite value: aBoolean
>> -------------
>>
>> If a default value can't be specified in the pragma, another way
>> consists in using a selector which
>> represents the message to send to the class in order to get the
>> default value:
>>
>> -------------
>> APreferencePrivider class>>standardFont
>>   <preference: 'The default system font' type: #LogicalFont set:
>> #standardFont: default: #defaultStandardFont description: 'The
>> default system font'>
>>   ^ StandardFont
>>       ifNil: [StandardFont := PreferenceValue value: self
>> defaultStandardFont location: self selector: #standardFont]
>>
>> APreferencePrivider class>>standardFont: aFont
>>   self standardFont value: aFont
>>  APreferencePrivider class>>defaultStandardFont
>>           ^ LogicalFont
>>                       familyName: 'Arial'
>>                       fallbackFamilyNames: nil
>>                       pointSize: 12
>>                       stretchValue: 5
>>                       weightValue: 400
>>                       slantValue: 0
>> -------------
>>
>> LISTENING TO A PREFERENCE VALUE CHANGE
>> Any object can register itself as a preference value change listener.
>> See #PreferenceCollector class>>whenChanged: inClass:notify:using:.
>>
>> Each time a preference value is changed, #preference:
>> inClass:changedWith: is sent to the PreferenceCollector class.
>>
>> Example of code a listener can implement in order to be notified each
>> time a gradientButtonLook preference defined by a PrefProvider class
>> is changed.
>> In this example, the listener ask to be notified by a send of
>> #gradientButtonLookIsNow: message.
>> The argument given to gradientButtonLookIsNow: is the new preference
>> value.
>> -------------
>>   ....
>>   PreferenceCollector whenChanged: #gradientButtonLook inClass:
>> PrefProvider notify: self using: #gradientButtonLookIsNow:.
>>   ....
>> -------------
>>
>> What do you think ?
>>
>> cheers
>> Alain
>>
>>
>> <Zoo-alain_plantec.10.mcz>_______________________________________________
>>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Alain Plantec-4
Stéphane
your previous question makes me think of a better solution
with requires only one mandatory class and which makes use of
standard event notification (without PreferenceCollector).

I've joined 4 packages :
- PrefCore contains PreferenceValue which is now the only mandatory class.

2 packages for testing:
- PrefProvider contains PrefProvider class which declares some preferences
- PrefUser contains PrefChangeListener (try PrefChangeListener test).

1 package for UI:
- PrefTool contains PreferenceCollector and PreferenceDefinition. They
are optional.

Code below do not makes use of PreferenceCollector anymore:

PrefChangeListener>>initialize
    super initialize.
    gradientLook := PrefProvider gradientButtonLook value. "reading of
the preference value"
    "Using of standard event notification engine"
    PrefProvider when: #gradientButtonLook send:
#gradientButtonLookIsNow: to: self.
    PrefProvider when: #gradientButtonLook send: #gradientLook: to: self.

Now, the preference system only need PreferenceValue.
PreferenceCollector and PreferenceDefinition are optional and can be brought
by a preference supporting tool (UI).

Previous version implied a dependency from PrefChangeListener to
PreferenceCollector which was bad.
PrefChangeListener>>initialize
    super initialize.
    gradientLook := PrefProvider gradientButtonLook value.
    PreferenceCollector whenChanged: #gradientButtonLook inClass:
PrefProvider notify: self using: #gradientButtonLookIsNow: .
    PreferenceCollector whenChanged: #gradientButtonLook inClass:
PrefProvider notify: self using: #gradientLook:

alain

Stéphane Ducasse a écrit :

> > sounds cool.
> > For me the most important aspect is that preferenceCollector (our
> > current preference class should be a removable layer on top
> > of the system that are declaring preference.
> >
> > Is is correct that
> >
> >  PreferenceCollector whenChanged: #gradientButtonLook inClass:
> > PrefProvider notify: self using: #gradientButtonLookIsNow: .
> >
> > means that PrefProvider will receive the message
> >         gradientButtonLookIsNow:
>  
no, but see the code below:
-----------
PrefListener>>initialize
    super initialize.
    PreferenceCollector whenChanged: #gradientButtonLook inClass:
PrefProvider notify: self using: #gradientButtonLookIsNow: .
-----------

it means that a PrefListener instance will receive the
#gradientButtonLookIsNow: message each time the preference
#gradientButtonLook defined in class PrefProvider is changed.

PrefListener and PrefProvider represent can  be any class in the system.
So, in order to read a preference value an object get it from the
provider class by message sending,
the provider is a class in a package which defines preferences (no need
for PreferenceCollector to get the preference value).

> >
> > This way we can push preference to the tools
>  
yes

> > and thety do not  have to query the information in the Collector at
> > run-time
>  
yes,
Each package have its own preference set in it represented by a set of
methods with pragma.
When such a package is loaded, its preferences are automatically stored
by PreferenceCollector.
When a package is removed, its preferences are automatically removed
from PreferenceCollector.
PreferenceCollector is only here for supporting tools (cool UI ...) and
for change notifications.


> > (hence we could remove Preference and have a more OO design).
>  
I guess yes.

> >
> > Sorry not to reply earlier (I was breaking yet another wall in our
> > "kitchen")
>  
bon courage  :)

alain

> >
> > Stef
> >
> >
> > On Mar 1, 2009, at 10:05 AM, Alain Plantec wrote:
> >
>  
>> >> Hi all,
>> >>
>> >> joined Zoo package is a attempt to translate in code what we
>> >> discussed  here before about preference refactoring.
>> >>
>> >> The framework is made of 3 classes: PreferenceCollector,
>> >> PreferenceDefinition and PreferenceValue.
>> >> In Zoo there are also 2 classes for testing: PrefProvider and
>> >> PrefChangeListener.
>> >> PrefProvider class declares some preferences and PrefChangeListener
>> >> is here to test preference change notification.
>> >>
>> >> PrefChangeListener>>initialize
>> >>   super initialize.
>> >>   PreferenceCollector whenChanged: #gradientButtonLook inClass:
>> >> PrefProvider notify: self using: #gradientButtonLookIsNow: .
>> >>   PreferenceCollector whenChanged: #gradientButtonLook inClass:
>> >> PrefProvider notify: self using: #gradientLook:
>> >>
>> >> PrefChangeListener class>>test
>> >>   "self test"
>> >>   PrefChangeListener new inspect.
>> >>   PrefProvider  gradientButtonLook: PrefProvider gradientButtonLook
>> >> value not.
>> >>   PrefProvider  gradientButtonLook: PrefProvider gradientButtonLook
>> >> value not.
>> >>   PrefProvider  gradientButtonLook: PrefProvider gradientButtonLook
>> >> value not.
>> >>
>> >>
>> >> From PreferenceCollector comment:
>> >> --------------------------------------
>> >> A PreferenceCollector automatically collects all preferences.
>> >> A preference is represented by a PreferenceDefinition.
>> >> All  PreferenceDefinition are stored in the preferences instance
>> >> variable.
>> >>
>> >> Instance Variables
>> >>   preferences:        OrderedCollection of PreferenceDefinition
>> >>
>> >> preferences
>> >>   - contains all PreferenceDefinition which are automatically built
>> >> from pragma found in preference getters
>> >>
>> >>
>> >> ADDING A PREFERENCE
>> >> PreferenceCollector makes use of the SystemChangeNotifier in order to
>> >> automate the adding, the removing and the updating of preferences.
>> >> See #PreferenceCollector>>event:  to see how preferences update is
>> >> implemented.
>> >>
>> >> Editing a new method with a preference pragma or inserting a
>> >> preference pragma in an existing method are
>> >> the two ways for preference definition adding.
>> >> The only way to remove a preference definition is to remove the
>> >> corresponding method.
>> >>
>> >> Example of a "blackAndWhite" preference.
>> >> Methods below are defined by the preference provider
>> >> APreferencePrivider class.
>> >> Note that the value stored in BlackAndWhite class variable is an
>> >> instance of PreferenceValue.
>> >> In this example, the default value is directly given with the pragma:
>> >> -------------
>> >> APreferencePrivider class>>blackAndWhite
>> >>   <preference: 'Use black and white' type: #Boolean set:
>> >> #blackAndWhite: defaultValue: false description: 'Use black and white'>
>> >>   ^ BlackAndWhite
>> >>       ifNil: [BlackAndWhite := PreferenceValue value: false location:
>> >> self selector: #blackAndWhite]
>> >>
>> >> APreferencePrivider class>>blackAndWhite: aBoolean
>> >>       self blackAndWhite value: aBoolean
>> >> -------------
>> >>
>> >> If a default value can't be specified in the pragma, another way
>> >> consists in using a selector which
>> >> represents the message to send to the class in order to get the
>> >> default value:
>> >>
>> >> -------------
>> >> APreferencePrivider class>>standardFont
>> >>   <preference: 'The default system font' type: #LogicalFont set:
>> >> #standardFont: default: #defaultStandardFont description: 'The
>> >> default system font'>
>> >>   ^ StandardFont
>> >>       ifNil: [StandardFont := PreferenceValue value: self
>> >> defaultStandardFont location: self selector: #standardFont]
>> >>
>> >> APreferencePrivider class>>standardFont: aFont
>> >>   self standardFont value: aFont
>> >>  APreferencePrivider class>>defaultStandardFont
>> >>           ^ LogicalFont
>> >>                       familyName: 'Arial'
>> >>                       fallbackFamilyNames: nil
>> >>                       pointSize: 12
>> >>                       stretchValue: 5
>> >>                       weightValue: 400
>> >>                       slantValue: 0
>> >> -------------
>> >>
>> >> LISTENING TO A PREFERENCE VALUE CHANGE
>> >> Any object can register itself as a preference value change listener.
>> >> See #PreferenceCollector class>>whenChanged: inClass:notify:using:.
>> >>
>> >> Each time a preference value is changed, #preference:
>> >> inClass:changedWith: is sent to the PreferenceCollector class.
>> >>
>> >> Example of code a listener can implement in order to be notified each
>> >> time a gradientButtonLook preference defined by a PrefProvider class
>> >> is changed.
>> >> In this example, the listener ask to be notified by a send of
>> >> #gradientButtonLookIsNow: message.
>> >> The argument given to gradientButtonLookIsNow: is the new preference
>> >> value.
>> >> -------------
>> >>   ....
>> >>   PreferenceCollector whenChanged: #gradientButtonLook inClass:
>> >> PrefProvider notify: self using: #gradientButtonLookIsNow:.
>> >>   ....
>> >> -------------
>> >>
>> >> What do you think ?
>> >>
>> >> cheers
>> >> Alain
>> >>
>> >>
>> >> <Zoo-alain_plantec.10.mcz>_______________________________________________
>> >>
>> >> 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





alain


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

PrefCore-alain_plantec.1.mcz (2K) Download Attachment
PrefListener-alain_plantec.3.mcz (2K) Download Attachment
PrefProvider-alain_plantec.1.mcz (3K) Download Attachment
PrefTool-alain_plantec.1.mcz (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Geert Claes
Administrator
Hi Alain, this sounds very interesting.  I have never been a big fan of the current "Preference Browser".  I am now trying to grasp (still learning here) how this new "Pharo Preference Mechanism" works.  It would be great if the mechanism could be explained in detail in something like the new Pharo By Example manual :)

Alain Plantec wrote
I've joined 4 packages :
- PrefCore contains PreferenceValue which is now the only mandatory class.

2 packages for testing:
- PrefProvider contains PrefProvider class which declares some preferences
- PrefUser contains PrefChangeListener (try PrefChangeListener test).

1 package for UI:
- PrefTool contains PreferenceCollector and PreferenceDefinition. They
are optional.
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Stéphane Ducasse

On Mar 2, 2009, at 4:44 AM, Geert wrote:

>
> Hi Alain, this sounds very interesting.  I have never been a big fan  
> of the
> current "Preference Browser".  I am now trying to grasp (still  
> learning
> here) how this new "Pharo Preference Mechanism" works.  It would be  
> great if
> the mechanism could be explained in detail in something like the new  
> Pharo
> By Example manual :)

this is a great idea.
if it is adopted I will write it.

>
> Alain Plantec wrote:
>>
>> I've joined 4 packages :
>> - PrefCore contains PreferenceValue which is now the only mandatory  
>> class.
>>
>> 2 packages for testing:
>> - PrefProvider contains PrefProvider class which declares some  
>> preferences
>> - PrefUser contains PrefChangeListener (try PrefChangeListener test).
>>
>> 1 package for UI:
>> - PrefTool contains PreferenceCollector and PreferenceDefinition.  
>> They
>> are optional.
>>
>
> --
> View this message in context: http://n2.nabble.com/Preference-refactoring-again-tp2403814p2407403.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Alain Plantec-4
In reply to this post by Geert Claes
Geert a écrit :
> Hi Alain, this sounds very interesting.
thanks
>   I have never been a big fan of the
> current "Preference Browser".
The main problem with current preference system is that it makes uses of
globals (declared in the class side of Preferences) and that a lot of
packages depend on it.
The main goal of the refactoring is to make preferences local to the
packages in which they are declared.
Current preference browser is not that bad and could be reused.
>   I am now trying to grasp (still learning
> here) how this new "Pharo Preference Mechanism" works.It would be great if
> the mechanism could be explained in detail in something like the new Pharo
> By Example manual :)
>  
Each preference is stored by a PreferenceValue instance and each time a
PreferenceValue is updated (with a #value: message sent) an event is
sent to the class which defines the preference. The event sending is
standard:
PreferenceValue>>value: anObject
    realValue ~= anObject
        ifTrue: [realValue := anObject.
            location triggerEvent: selector with: anObject]

realValue is the instance variable wich stores current preference value.
location is the class which declares the preference
selector is the selector of the preference (i.e. #gradientButtonLook)

So my proposition is to declare a preference locally. Let's take the
example of freetype monitorTypeLCD preference.
If we implement it the way it is now, as a boolean, it could be:
---------------
FreeTypeSettings class>>monitorTypeLCD
    <preference: 'LCD monitor type' type: #Boolean set: #monitorTypeLCD:
defaultValue: false description: 'Use of a LCD...'>
    ^ MonitorTypeLCD
        ifNil: [MonitorTypeLCD := PreferenceValue value: false location:
self selector: #monitorTypeLCD]

FreeTypeSettings class>>monitorTypeLCD: aBoolean
    self monitorTypeLCD value: hintingFull

FreeTypeSettings class>>initialize
     FreeTypeSettings when: #monitorTypeLCD send:
#monitorTypeLCDPreferenceChanged: to: self.

FreeTypeSettings class>>monitorTypeLCDPreferenceChanged: aBoolean
    self current monitorTypeLCDPreferenceChanged: aBoolean
-------------
The pragma you see in FreeTypeSettings class>>monitorTypeLCD in only
here for UI tools such as PreferenceBrowser.

If a client object needs monitorTypeLCD value, it asks directly to its
provider which is FreeTypeSettings class:
    ...
    useLCD := FreeTypeSettings monitorTypeLCD value.
    ...

but note that such a preference should be set as a choice between two
values #LCD or #CRT...

hope things are a little bit clearer now.
alain

>
> Alain Plantec wrote:
>  
>> I've joined 4 packages :
>> - PrefCore contains PreferenceValue which is now the only mandatory class.
>>
>> 2 packages for testing:
>> - PrefProvider contains PrefProvider class which declares some preferences
>> - PrefUser contains PrefChangeListener (try PrefChangeListener test).
>>
>> 1 package for UI:
>> - PrefTool contains PreferenceCollector and PreferenceDefinition. They
>> are optional.
>>
>>    
>
>  


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Gary Chambers-4
Looks good. Is there really a need for a PreferenceValue class though?

I'm concerned that the getter returns a different kind of object to that
expected by the setter...
For any preference tool the presence of the pragma is sufficient to get/set
the native value and, assuming always class-side, support event triggering
for changes.

Regards, Gary

----- Original Message -----
From: "Alain Plantec" <[hidden email]>
To: <[hidden email]>
Sent: Monday, March 02, 2009 8:41 AM
Subject: Re: [Pharo-project] Preference refactoring again


Geert a écrit :
> Hi Alain, this sounds very interesting.
thanks
>   I have never been a big fan of the
> current "Preference Browser".
The main problem with current preference system is that it makes uses of
globals (declared in the class side of Preferences) and that a lot of
packages depend on it.
The main goal of the refactoring is to make preferences local to the
packages in which they are declared.
Current preference browser is not that bad and could be reused.
>   I am now trying to grasp (still learning
> here) how this new "Pharo Preference Mechanism" works.It would be great if
> the mechanism could be explained in detail in something like the new Pharo
> By Example manual :)
>
Each preference is stored by a PreferenceValue instance and each time a
PreferenceValue is updated (with a #value: message sent) an event is
sent to the class which defines the preference. The event sending is
standard:
PreferenceValue>>value: anObject
    realValue ~= anObject
        ifTrue: [realValue := anObject.
            location triggerEvent: selector with: anObject]

realValue is the instance variable wich stores current preference value.
location is the class which declares the preference
selector is the selector of the preference (i.e. #gradientButtonLook)

So my proposition is to declare a preference locally. Let's take the
example of freetype monitorTypeLCD preference.
If we implement it the way it is now, as a boolean, it could be:
---------------
FreeTypeSettings class>>monitorTypeLCD
    <preference: 'LCD monitor type' type: #Boolean set: #monitorTypeLCD:
defaultValue: false description: 'Use of a LCD...'>
    ^ MonitorTypeLCD
        ifNil: [MonitorTypeLCD := PreferenceValue value: false location:
self selector: #monitorTypeLCD]

FreeTypeSettings class>>monitorTypeLCD: aBoolean
    self monitorTypeLCD value: hintingFull

FreeTypeSettings class>>initialize
     FreeTypeSettings when: #monitorTypeLCD send:
#monitorTypeLCDPreferenceChanged: to: self.

FreeTypeSettings class>>monitorTypeLCDPreferenceChanged: aBoolean
    self current monitorTypeLCDPreferenceChanged: aBoolean
-------------
The pragma you see in FreeTypeSettings class>>monitorTypeLCD in only
here for UI tools such as PreferenceBrowser.

If a client object needs monitorTypeLCD value, it asks directly to its
provider which is FreeTypeSettings class:
    ...
    useLCD := FreeTypeSettings monitorTypeLCD value.
    ...

but note that such a preference should be set as a choice between two
values #LCD or #CRT...

hope things are a little bit clearer now.
alain

>
> Alain Plantec wrote:
>
>> I've joined 4 packages :
>> - PrefCore contains PreferenceValue which is now the only mandatory
>> class.
>>
>> 2 packages for testing:
>> - PrefProvider contains PrefProvider class which declares some
>> preferences
>> - PrefUser contains PrefChangeListener (try PrefChangeListener test).
>>
>> 1 package for UI:
>> - PrefTool contains PreferenceCollector and PreferenceDefinition. They
>> are optional.
>>
>>
>
>


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Alain Plantec-4
Gary Chambers a écrit :

Hi Gary,
> Looks good. Is there really a need for a PreferenceValue class though?
>
> I'm concerned that the getter returns a different kind of object to
> that expected by the setter...
yes, ok

FreeTypeSettings class>>monitorTypeLCD
  <preference: 'LCD monitor type' type: #Boolean set: #monitorTypeLCD:
defaultValue: false description: 'Use of a LCD...'>
  ^ (MonitorTypeLCD
      ifNil: [MonitorTypeLCD := PreferenceValue value: false location:
self selector: #monitorTypeLCD]) value

> For any preference tool the presence of the pragma is sufficient to
> get/set the native value and, assuming always class-side, support
> event triggering for changes.
I'm not sure to understand.
you suggest a solution like this ? :
FreeTypeSettings class>>monitorTypeLCD: aBoolean
   monitorTypeLCD := aBoolean.
   self triggerEvent: #monitorTypeLCD with: aBoolean

Of course, then you do not need PreferenceValue.
But I prefer PreferenceValue solution because it encapsulates the
triggerEvent,  the developper do not have to deal
with it and it is more evolutive (it is easy to change the way events
are triggered or to change the notification framework).

regarding the pragma use, I see it as only useful from supporting tools
(PreferencesBrowser...).
but maybe I'm wrong, let me know.

Cheers
Alain

>
> Regards, Gary
>
> ----- Original Message ----- From: "Alain Plantec"
> <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, March 02, 2009 8:41 AM
> Subject: Re: [Pharo-project] Preference refactoring again
>
>
> Geert a écrit :
>> Hi Alain, this sounds very interesting.
> thanks
>>   I have never been a big fan of the
>> current "Preference Browser".
> The main problem with current preference system is that it makes uses of
> globals (declared in the class side of Preferences) and that a lot of
> packages depend on it.
> The main goal of the refactoring is to make preferences local to the
> packages in which they are declared.
> Current preference browser is not that bad and could be reused.
>>   I am now trying to grasp (still learning
>> here) how this new "Pharo Preference Mechanism" works.It would be
>> great if
>> the mechanism could be explained in detail in something like the new
>> Pharo
>> By Example manual :)
>>
> Each preference is stored by a PreferenceValue instance and each time a
> PreferenceValue is updated (with a #value: message sent) an event is
> sent to the class which defines the preference. The event sending is
> standard:
> PreferenceValue>>value: anObject
>    realValue ~= anObject
>        ifTrue: [realValue := anObject.
>            location triggerEvent: selector with: anObject]
>
> realValue is the instance variable wich stores current preference value.
> location is the class which declares the preference
> selector is the selector of the preference (i.e. #gradientButtonLook)
>
> So my proposition is to declare a preference locally. Let's take the
> example of freetype monitorTypeLCD preference.
> If we implement it the way it is now, as a boolean, it could be:
> ---------------
> FreeTypeSettings class>>monitorTypeLCD
>    <preference: 'LCD monitor type' type: #Boolean set: #monitorTypeLCD:
> defaultValue: false description: 'Use of a LCD...'>
>    ^ MonitorTypeLCD
>        ifNil: [MonitorTypeLCD := PreferenceValue value: false location:
> self selector: #monitorTypeLCD]
>
> FreeTypeSettings class>>monitorTypeLCD: aBoolean
>    self monitorTypeLCD value: hintingFull
>
> FreeTypeSettings class>>initialize
>     FreeTypeSettings when: #monitorTypeLCD send:
> #monitorTypeLCDPreferenceChanged: to: self.
>
> FreeTypeSettings class>>monitorTypeLCDPreferenceChanged: aBoolean
>    self current monitorTypeLCDPreferenceChanged: aBoolean
> -------------
> The pragma you see in FreeTypeSettings class>>monitorTypeLCD in only
> here for UI tools such as PreferenceBrowser.
>
> If a client object needs monitorTypeLCD value, it asks directly to its
> provider which is FreeTypeSettings class:
>    ...
>    useLCD := FreeTypeSettings monitorTypeLCD value.
>    ...
>
> but note that such a preference should be set as a choice between two
> values #LCD or #CRT...
>
> hope things are a little bit clearer now.
> alain
>>
>> Alain Plantec wrote:
>>
>>> I've joined 4 packages :
>>> - PrefCore contains PreferenceValue which is now the only mandatory
>>> class.
>>>
>>> 2 packages for testing:
>>> - PrefProvider contains PrefProvider class which declares some
>>> preferences
>>> - PrefUser contains PrefChangeListener (try PrefChangeListener test).
>>>
>>> 1 package for UI:
>>> - PrefTool contains PreferenceCollector and PreferenceDefinition. They
>>> are optional.
>>>
>>>
>>
>>
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Geert Claes
Administrator
In reply to this post by Alain Plantec-4
Alain Plantec wrote
The pragma you see in ...
I can't seem to find a lot of info on the "pragmas" people are referring to, what are they exactly, when or what should they be used for, how do they work ...?  Maybe another one for the book Stef :)
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Alain Plantec-4
In reply to this post by Gary Chambers-4
Gary Chambers a écrit :

> In that case perhaps the setter should expect a PreferenceValue or
> native and internally store
> one after setting its value.
>
> Not quite clear what should be stored in the class var from the code
> snippet.
>
> Perhaps the following is simpler if the PreferenceValue does the
> handling:
>
> FreeTypeSettings class>>monitorTypeLCD
>   <preference: 'LCD monitor type' type: #Boolean defaultValue: false
> description: 'Use of a LCD...'>
>   ^ MonitorTypeLCD
>           ifNil: [MonitorTypeLCD := PreferenceValue value: false]
>
> Then to get is
>
> FreeTypeSettings monitorTypeLCD value
>
> and to set is
>
> FreeTypeSettings monitorTypeLCD value: true
yes, it is better

>
> the PreferenceValue handles the notifications...
>
> FreeTypeSettings class>>initialize
>     self monitorStyleLCD when: #valueChanged send:
> #monitorTypeLCDPreferenceChanged: to: self
>
> PreferenceValue>>value: anObject
>    realValue ~= anObject
>        ifTrue: [realValue := anObject.
>            self triggerEvent: #valueChanged with: anObject]
cool,  better again
happy to learn  :)
>
> Tools can just pick up the pragma and not have to worry about setters,
> "location" etc.
ok

> Perhaps the PreferenceValue could hold the types/description too to
> help tools...
>
> FreeTypeSettings class>>monitorTypeLCD
>   <preference>
>   ^ MonitorTypeLCD ifNil: [
>          MonitorTypeLCD := PreferenceValue
>                name: 'LCD monitor type'
>                type: #Boolean
>                value: false
>                default: false
>                decsription: 'Use of a LCD...']
could be ok for me, anyway what do you think of:

FreeTypeSettings class>>monitorTypeLCD
  <preference: 'LCD monitor type' type: #Boolean decsription: 'Use of a
LCD...'>
  ^ MonitorTypeLCD ifNil: [ MonitorTypeLCD := PreferenceValue value:
false default: false]

Name, type and description are only useful from PreferenceBrowser point
of view (preference helper)
whereas a PreferenceValue is concerned by its value and its default.
>
> Here the pragma is a simple marker to identify the selector as a
> preference returner.
>
> Of course, deliberately overwriting the class var directly will mean
> that notification subscribers will become disassociated...
If I well understand, I consider this as a bad pratice which should be
detected by a lint rule.
so, it is not a problem for me

Cheers
Alain

>
>
> Simpler the better perhaps though.
>
> Regards, Gary
>
> ----- Original Message ----- From: "Alain Plantec" <[hidden email]>
> To: "Gary Chambers" <[hidden email]>
> Sent: Monday, March 02, 2009 11:05 AM
> Subject: Re: [Pharo-project] Preference refactoring again
>
>
>> Gary Chambers a écrit :
>>
>> Hi Gary,
>>> Looks good. Is there really a need for a PreferenceValue class though?
>>>
>>> I'm concerned that the getter returns a different kind of object to
>>> that expected by the setter...
>> yes, ok
>>
>> FreeTypeSettings class>>monitorTypeLCD
>>   <preference: 'LCD monitor type' type: #Boolean set:
>> #monitorTypeLCD: defaultValue: false description: 'Use of a LCD...'>
>>   ^ (MonitorTypeLCD
>>       ifNil: [MonitorTypeLCD := PreferenceValue value: false
>> location: self selector: #monitorTypeLCD]) value
>>
>>> For any preference tool the presence of the pragma is sufficient to
>>> get/set the native value and, assuming always class-side, support
>>> event triggering for changes.
>> I'm not sure to understand.
>> you suggest a solution like this ? :
>> FreeTypeSettings class>>monitorTypeLCD: aBoolean
>>    monitorTypeLCD := aBoolean.
>>    self triggerEvent: #monitorTypeLCD with: aBoolean
>>
>> Of course, then you do not need PreferenceValue.
>> But I prefer PreferenceValue solution because it encapsulates the
>> triggerEvent,  the developper do not have to deal
>> with it and it is more evolutive (it is easy to change the way events
>> are triggered or to change the notification framework).
>>
>> regarding the pragma use, I see it as only useful from supporting
>> tools (PreferencesBrowser...).
>> but maybe I'm wrong, let me know.
>>
>> Cheers
>> Alain


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Alain Plantec-4
Alain Plantec a écrit :

>> Perhaps the PreferenceValue could hold the types/description too to
>> help tools...
>>
>> FreeTypeSettings class>>monitorTypeLCD
>>   <preference>
>>   ^ MonitorTypeLCD ifNil: [
>>          MonitorTypeLCD := PreferenceValue
>>                name: 'LCD monitor type'
>>                type: #Boolean
>>                value: false
>>                default: false
>>                decsription: 'Use of a LCD...']
>>    
> could be ok for me, anyway what do you think of:
>
> FreeTypeSettings class>>monitorTypeLCD
>   <preference: 'LCD monitor type' type: #Boolean decsription: 'Use of a
> LCD...'>
>   ^ MonitorTypeLCD ifNil: [ MonitorTypeLCD := PreferenceValue value:
> false default: false]
>
> Name, type and description are only useful from PreferenceBrowser point
> of view (preference helper)
> whereas a PreferenceValue is concerned by its value and its default.
>  
or simply  :

FreeTypeSettings class>>monitorTypeLCD
  <preference:'LCD monitor type' type:#Boolean decsription:'Use of a LCD...'>
  ^ MonitorTypeLCD ifNil: [MonitorTypeLCD := PreferenceValue default:false]



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Tapple Gao
On Mon, Mar 02, 2009 at 01:59:03PM +0100, Alain Plantec wrote:
> or simply  :
>
> FreeTypeSettings class>>monitorTypeLCD
>   <preference:'LCD monitor type' type:#Boolean decsription:'Use of a LCD...'>
>   ^ MonitorTypeLCD ifNil: [MonitorTypeLCD := PreferenceValue default:false]

Did anybody ever notice my suggestion to use Magritte for
Preferences?

http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005489.html

----- Forwarded message from Matthew Fulmer <[hidden email]> -----

From: Matthew Fulmer <[hidden email]>
To: [hidden email]
Date: Mon, 16 Feb 2009 15:15:55 -0500
Subject: Re: [Pharo-project] Preferences refactoring

On Mon, Feb 16, 2009 at 02:19:55PM -0500, Matthew Fulmer wrote:

> On Mon, Feb 16, 2009 at 05:32:33PM -0000, Gary Chambers wrote:
> > So, for new browser it needs to be decided what information to show as this
> > will affect the pragma.
> > For instance, do we still want categories, "project specific" (probably not)
> > etc.
> >
> > I expect we will want a Preference class either way to model each preference
> > in the browser.
> > Making a new browser is quite an undertaking given the different types of
> > preference (boolean, text, one-of-many, colour, font etc.).
>
> I think Magritte is the proper solution. It already handles UI
> metadata like this.

Something like this:

prefTheme
    <preference category: 'User Interface'>
    ^ MASingleOptionDescription new
        options: #( 'Vistary' 'Watery' 'Squeak' 'Soft Squeak' );
        reference: MAStringDescription new;
        autoAccessor: 'theme';
        label: 'Theme';
        priority: 40;
        beSorted;
        yourself

> Regarding preferences being optional, I think just a few tweaks
> to the MC loader would work: If the Preferences Browser is not
> loaded, MC will not compile the methods that return the Magritte
> metadata. If this is done properly, as in MC1.5, these methods
> will hang out uncompiled in the orphanage until you load the
> preferences package, at which point they will be loaded into the
> image.

This is completely wrong. In the above example, if Magritte was
not loaded, MASingleOptionDescription will bind to Undeclared.
Then, if Magritte is ever loaded, it will notice the reference
in Undeclared, and recompile this method to act correctly.

> Out-of-order package loading is nice.

Out-of-order loading, in the form of global references, has been
supported since smalltalk-76 by the Undeclared object.

The MC1.5 orphanage supports another kind of out-of-order
loading, in addition to that supported by Undeclared. But it is
irrelavant in this example.

----- End forwarded message -----

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Alain Plantec-4
Matthew Fulmer a écrit :
> Did anybody ever notice my suggestion to use Magritte for
> Preferences?
>
> http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005489.html
>
>  
Hi Matthew,
one should have answer something to you. sorry.
First I know what magritte is but I've never tried it so I can't give an
opinion if it is desirable, possible...
But magritte is not a part of Pharo-core. Is it planned to include it ?
What I'm trying to do (with a big help from Gary) is to implement a
proposition so people can
make their own opinion and say if it is ok or not.
I will post a new one soon (I hope), maybe you can have a look and
propose something  with Magritte.
Cheers
alain



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Igor Stasenko
Looks nice (especially integration with notifications).

Just a single straw hat man question:

- how you dealing with a preferences which declared multiple times
under the same name:

MyAlphaClass class>>enabled
  <preference: 'enabled' type: #Boolean set: #setEnabled: default:
#false  description: 'Alpha thingy enabled'>

MyBetaClass class>>enabled
  <preference: 'enabled' type: #Boolean set: #setEnabled: default:
#false  description: 'Beta thingy enabled'>

it also seem would be nice to have a preference category name(s)


2009/3/2 Alain Plantec <[hidden email]>:

> Matthew Fulmer a écrit :
>> Did anybody ever notice my suggestion to use Magritte for
>> Preferences?
>>
>> http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005489.html
>>
>>
> Hi Matthew,
> one should have answer something to you. sorry.
> First I know what magritte is but I've never tried it so I can't give an
> opinion if it is desirable, possible...
> But magritte is not a part of Pharo-core. Is it planned to include it ?
> What I'm trying to do (with a big help from Gary) is to implement a
> proposition so people can
> make their own opinion and say if it is ok or not.
> I will post a new one soon (I hope), maybe you can have a look and
> propose something  with Magritte.
> Cheers
> alain
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Alain Plantec-4
Igor Stasenko a écrit :

> Looks nice (especially integration with notifications).
>
> Just a single straw hat man question:
>
> - how you dealing with a preferences which declared multiple times
> under the same name:
>
> MyAlphaClass class>>enabled
>   <preference: 'enabled' type: #Boolean set: #setEnabled: default:
> #false  description: 'Alpha thingy enabled'>
>
> MyBetaClass class>>enabled
>   <preference: 'enabled' type: #Boolean set: #setEnabled: default:
> #false  description: 'Beta thingy enabled'>
>  
Hi Igor,
When a pragma is collected, the name of the class in wich the pragma is
defined is available.

> it also seem would be nice to have a preference category name(s)
>  
yes, it will be added.
thanks for your remarks.
alain

>
> 2009/3/2 Alain Plantec <[hidden email]>:
>  
>> Matthew Fulmer a écrit :
>>    
>>> Did anybody ever notice my suggestion to use Magritte for
>>> Preferences?
>>>
>>> http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005489.html
>>>
>>>
>>>      
>> Hi Matthew,
>> one should have answer something to you. sorry.
>> First I know what magritte is but I've never tried it so I can't give an
>> opinion if it is desirable, possible...
>> But magritte is not a part of Pharo-core. Is it planned to include it ?
>> What I'm trying to do (with a big help from Gary) is to implement a
>> proposition so people can
>> make their own opinion and say if it is ok or not.
>> I will post a new one soon (I hope), maybe you can have a look and
>> propose something  with Magritte.
>> Cheers
>> alain
>>
>>
>>
>> _______________________________________________
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Stéphane Ducasse
In reply to this post by Alain Plantec-4

On Mar 2, 2009, at 10:05 PM, Alain Plantec wrote:

> Matthew Fulmer a écrit :
>> Did anybody ever notice my suggestion to use Magritte for
>> Preferences?
>>
>> http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005489.html
>>
>>
> Hi Matthew,
> one should have answer something to you. sorry.
> First I know what magritte is but I've never tried it so I can't  
> give an
> opinion if it is desirable, possible...
> But magritte is not a part of Pharo-core. Is it planned to include  
> it ?

No and it will not be.
>
> What I'm trying to do (with a big help from Gary) is to implement a
> proposition so people can
> make their own opinion and say if it is ok or not.
> I will post a new one soon (I hope), maybe you can have a look and
> propose something  with Magritte.

Magritte is decorating class with metadescription and building
interpreters on top of it.

>
> Cheers
> alain
>
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Alexandre Bergel
In reply to this post by Tapple Gao
This will probably work and seems reasonable in a general context.
However, for our situation, I feel these are on different levels.  
Preferences should be defined and taken into account in Pharo-core,  
meaning without Magritte.

Cheers,
Alexandre


On 2 Mar 2009, at 18:03, Matthew Fulmer wrote:

> On Mon, Mar 02, 2009 at 01:59:03PM +0100, Alain Plantec wrote:
>> or simply  :
>>
>> FreeTypeSettings class>>monitorTypeLCD
>>  <preference:'LCD monitor type' type:#Boolean decsription:'Use of a  
>> LCD...'>
>>  ^ MonitorTypeLCD ifNil: [MonitorTypeLCD := PreferenceValue  
>> default:false]
>
> Did anybody ever notice my suggestion to use Magritte for
> Preferences?
>
> http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005489.html
>
> ----- Forwarded message from Matthew Fulmer <[hidden email]> -----
>
> From: Matthew Fulmer <[hidden email]>
> To: [hidden email]
> Date: Mon, 16 Feb 2009 15:15:55 -0500
> Subject: Re: [Pharo-project] Preferences refactoring
>
> On Mon, Feb 16, 2009 at 02:19:55PM -0500, Matthew Fulmer wrote:
>> On Mon, Feb 16, 2009 at 05:32:33PM -0000, Gary Chambers wrote:
>>> So, for new browser it needs to be decided what information to  
>>> show as this
>>> will affect the pragma.
>>> For instance, do we still want categories, "project  
>>> specific" (probably not)
>>> etc.
>>>
>>> I expect we will want a Preference class either way to model each  
>>> preference
>>> in the browser.
>>> Making a new browser is quite an undertaking given the different  
>>> types of
>>> preference (boolean, text, one-of-many, colour, font etc.).
>>
>> I think Magritte is the proper solution. It already handles UI
>> metadata like this.
>
> Something like this:
>
> prefTheme
>    <preference category: 'User Interface'>
>    ^ MASingleOptionDescription new
>        options: #( 'Vistary' 'Watery' 'Squeak' 'Soft Squeak' );
>        reference: MAStringDescription new;
>        autoAccessor: 'theme';
>        label: 'Theme';
>        priority: 40;
>        beSorted;
>        yourself
>
>> Regarding preferences being optional, I think just a few tweaks
>> to the MC loader would work: If the Preferences Browser is not
>> loaded, MC will not compile the methods that return the Magritte
>> metadata. If this is done properly, as in MC1.5, these methods
>> will hang out uncompiled in the orphanage until you load the
>> preferences package, at which point they will be loaded into the
>> image.
>
> This is completely wrong. In the above example, if Magritte was
> not loaded, MASingleOptionDescription will bind to Undeclared.
> Then, if Magritte is ever loaded, it will notice the reference
> in Undeclared, and recompile this method to act correctly.
>
>> Out-of-order package loading is nice.
>
> Out-of-order loading, in the form of global references, has been
> supported since smalltalk-76 by the Undeclared object.
>
> The MC1.5 orphanage supports another kind of out-of-order
> loading, in addition to that supported by Undeclared. But it is
> irrelavant in this example.
>
> ----- End forwarded message -----
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Tapple Gao
On Tue, Mar 03, 2009 at 06:58:26PM +0100, Alexandre Bergel wrote:
> This will probably work and seems reasonable in a general context.
> However, for our situation, I feel these are on different levels.  
> Preferences should be defined and taken into account in Pharo-core,  
> meaning without Magritte.

Hmm. I'd think pharo-core would not have preferences.

I was just suggesting it; it seems that once you implement
enough to have generic boolean, string, or enumerable
preferences, you basically have a watered-down magritte anyway.
And who's to say we won't want a generic timezone, email
address, or url preference in the future? Magritte can do those
without having to rewrite string parsing/verification into every
class.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Preference refactoring again

Stéphane Ducasse
>> I was just suggesting it; it seems that once you implement
> enough to have generic boolean, string, or enumerable
> preferences, you basically have a watered-down magritte anyway.
> And who's to say we won't want a generic timezone, email
> address, or url preference in the future? Magritte can do those
> without having to rewrite string parsing/verification into every
> class.

indeed. But I do not see how the magritte description** pattern would  
work for preferences.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project