I did not follow in detail but my gut feeling is the following one: - keep the preference browser as a layer on top of the rest - change the preferences default and move them into the tools (pragmas there). - change the flow to not query the preference class during the execution of the tools.
I will try to get back my brain to read the thread. stef On Feb 16, 2009, at 6:32 PM, 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.). > > 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 > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
