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" <alain.plantec@free.fr> To: <Pharo-project@lists.gforge.inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project