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" <[email protected]> To: <[email protected]> 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
