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