Hi alain
> Hi all,
> Here is a Preference engine based on pragma.
> please, check it and tell me if it is ok or not.
> If you prefer squeak version,
this will be difficult :)
I reread all the emails you exchanged with gary and igor.
What is a parentNode in AbtsractPreferenceValue?
This is when you have a composite preference?
I understood when reading the code of PrefProvider2
> no problem but tell me
> that I stop working on this.
>
> The set of system preferences constitutes a tree of preferences.
> The model for the tree is implemented by the PreferenceNode hierarchy.
> (see PrefCore2). This is the only mandatory part.
> The tree can be visualized with a PreferenceTree UI built on top of
> PrefCore2 (see PrefTool2 and snapshot).
> Examples of preference declaration are given in PrefProvider2.
> in order to open the tree:
> PreferenceTree open
I have two naive questions:
- I imagine that we will be able to reuse the Preference browser and
that we do not have to rebuild one?
because the pragma preference collector could be put there? Or is it
better to rewrite everything?
- second I was wondering why you only use <preference> and not
<preference:zork:> like in andreas solution?
Gary mentioned that some objects can be more complex than mere literal.
I was wondering if for the interface it would not be better to have
cascaded selector instead of
methods with multiple argument.
PreferenceNode name: 'HTTP proxy' description: 'http proxy name and
port' parent: #networkPreferenceNode
vs
PreferenceNode new
name: 'HTTP proxy' ;
description: 'http proxy name and port' ;
parent: #networkPreferenceNode
So can I summarize your approach as follow?
- packages can defined locally their preferences (by construction
this will be better
since people will have to think about preferences value as their
stuff. not the one of preference
so this will help the flow to be local --- good.
- preferences are not centralized anymore (youpi)
- tools can register to get notified when preferences changes
- preferences can be complex objects
- preferences are structured in preferences tree.
Sounds cool to me. I will let the other give their point of view.
I'm leaving on vacation now.
Stef
PS: test should be
"self test"
PrefChangeListener new inspect.
UIPreferences gradientButtonLook value: UIPreferences
gradientButtonLook value not.
UIPreferences gradientButtonLook value: UIPreferences
gradientButtonLook value not.
UIPreferences gradientButtonLook value: UIPreferences
gradientButtonLook value not.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
