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