Re: [Pharo-project] Preference refactoring again
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" <beranger22@gmail.com> To: "Gary Chambers" <gazzaguru2@btinternet.com> 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
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]
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.ht... ----- Forwarded message from Matthew Fulmer <tapplek@gmail.com> ----- From: Matthew Fulmer <tapplek@gmail.com> To: pharo-project@lists.gforge.inria.fr 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/
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.ht...
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
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 <alain.plantec@free.fr>:
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.ht...
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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 <alain.plantec@free.fr>:
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.ht...
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.ht...
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.ht...
----- Forwarded message from Matthew Fulmer <tapplek@gmail.com> -----
From: Matthew Fulmer <tapplek@gmail.com> To: pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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/
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.
participants (5)
-
Alain Plantec -
Alexandre Bergel -
Igor Stasenko -
Matthew Fulmer -
Stéphane Ducasse