Fair. I guess a simplified version of the announcement pattern could be used for notification. Of course, to avoid repeating code one might want a Preferences instance (not like the current Preferences class stuff) that can be registered with for those classses supporting preferences. E.g. for a subscriber: XYZClass preferences observe: #windowColor do: [:pref | ...] And for a preferences supplier you might have the Preferences instance referenced by a class var or something. Regards, Gary ----- Original Message ----- From: "Michael Rueger" <m.rueger@acm.org> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, February 16, 2009 3:50 PM Subject: Re: [Pharo-project] Preferences refactoring
Gary Chambers wrote:
I'll have a think. Some theme settings can currently be set (manually) on a per theme basis. Would be nice to handle that, though the pragma route suggests that a static facade would be needed to delegate to the defaults for the current theme...
I'd see something like
X class>>myPreference <preference: 'Readable name' type: #Boolean set: #myPreference: default: #defaultMyPreference description: 'Helpful text'> ^ myPreference ifNil: [myPreference := self defaultMyPreference]
In Sophie we have a Preference system supporting user and system level preferences as well as preference definitions similar to the one above.
In my ySqueak experiments I extended that so classes can register as "preference provider" and also as listeners to preference changes.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project