Stéphane Ducasse a écrit :
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? yes 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? I guess we can reuse some parts.
- 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. and he convinced me not to use <preference:zork:> for two main reasons -Only one model for preference in the image (no need to retrieve the pragma or to store them in a second model) -<preference:zork:> is flat, it allow on literals as parameters, so it is very difficult to describe composites
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 ok for me.
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. exactly
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. yes, this is the version you have in PrefListener.5.mcz
alain