Re: [Pharo-project] Preferences refactoring

Feb. 16, 2009

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

Regards, Gary