So let us know when we integrate it :) Stef
> 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 > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
