Re: [Pharo-project] Preferences refactoring

Feb. 16, 2009

      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 
(the class may have extensions allowing it to work with the 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).

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]

This means that we can retain the categorisation of preferences and existing 
editing machinery etc.

All pretty hideous, one way or another...

Regards, Gary

----- Original Message ----- 
From: "Alain Plantec" <beranger22@gmail.com>
To: <Pharo-project@lists.gforge.inria.fr>
Sent: Monday, February 16, 2009 2:15 PM
Subject: Re: [Pharo-project] Preferences refactoring

Alain Plantec a Ã©crit :
...
Alain Plantec a Ã©crit :
...
Gary Chambers a Ã©crit :
...
Not sure I like having the code changed all the time.
If the code is changed then the MC package will show changes...
ok, but I liked the idea of not to have variable for simple preferences.
and not to be forced to use a particular tool or an inspector in order
to change a preference.
just use your favorite browser.
alain
ok one can have:
XX class>>myPreference: aValue
    "self myPreference: myValue"
    myPreference := aValue

and the user edits the comment of the setter and evaluates it without
saving the code.
Cheers
alain
...
...
a solution could be to use update notification. in the case of a
preference -> do not implies package change.
But I can agry with your solution easily. :)
.....
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project