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.). Regards, Gary. ----- Original Message ----- From: "Alain Plantec" <[email protected]> To: <[email protected]> Sent: Monday, February 16, 2009 5:08 PM Subject: Re: [Pharo-project] Preferences refactoring Gary Chambers a écrit : > 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] > > X class>>defaultMyPreference > ^false > > X class>>myPreference: aTValue > myPreference := aTValue. > "do any stuff to notify/apply change..." > > That would be enough got get the value (selector of pragma) and all > the rest. The default value needs to be by method since pragma > arguents only support literals (some preferences may be complex > objects). The type can be used by the preference browser to determine > how to handle the values... I suggest having the class name of the > expected value here to help with that ok, this is what I suggested also (all informations are explicitly declared with pragma) > (the class may have extensions allowing it to work with the preference > browser). i'm not sure it is a good idea to keep the current preference browser ... > > Of course, another approach is to just decentralize the preferences... > > X class>>xyzColorPreference > <preference> > ^Preference new > name: #xyzColor > defaultValue: Color red > helpString: 'Specifies the xyz color of abc' > localToProject: false > categoryList: #(#'window colors') > changeInformee: self > changeSelector: #xyzColor: > viewRegistry: (PreferenceViewRegistry registryOf: > #windowColorPreferences) > > And tweak Preference>>notifyInformeeOfChange to handle the argument > for the changeSelector (passing the new preference value). * I prefer previous solution. Maybe we need a Preference class but I'm not sure. > > That should work ok with the existing preference browser with a few > tweaks (the preference browser should have a its preferences var set > to a new instance of a class that provides the relevant protocol that > is used on the Preference class side but with the preferences > discovered via the code below). > > (Object withAllSubclasses > inject: OrderedCollection new > into: [:pragmas :class | pragmas, (Pragma allNamed: #preference in: > class)]) > collect: [:pragma | pragma methodClass theNonMetaClass perform: pragma > selector] yes, cool code :) alain _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Regards, Gary _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
