<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi all, The Preference model in Cuis, to my current knowledge, is composed of two classes: Preferences and Preference. I will write down the analysis of how it is working Preference. Its instance defines one preference facet, its initial design is clearly targeted for boolean but there are use case for non boolean. There instances variables are: <ul> <li>name helpString - symbol name and detailed description </li> <li>value defaultValue - current value and a default value. Most value are boolean but some Preference instance comes with a non boolean value, without possibility to know its type, the method to toggle the value then breaks. </li> <li>categoryList - an array of selector describing the categories the preference belongs to. I think one selector is enough. Opinion? </li> <li>changeInformee changeSelector - an object and selector to inform of value changed. I don't think it is good design, it is limited to one object and it should use triggerEvent. Opinion?</li> </ul> To overcome the limitation of Preference mode, we could have subclasses of Preference, each specialized in one form of preference model: list, free text, closure, boolean, integer, integer in an interval, color, etc. Each one could be then extended in a third party package with the appropriate widget to edit its content. Preferences. This is where the preferences are stored. The behavior is only in the class side, with two class variables. For me there is a concern with the responsibilities. For example there are methods to set the particular state of a Preference instance. For example #forTouch. I don't think it belongs there. In short the class is a bit a mess, 167 methods. Opinion? <ul> <li>DictionaryOfPreferences - Hold the Preference instances. </li> <li>Parameters - Unclear. Opinion? </li> </ul> The way to query the preferences is what make the class method numerous in Preferences. Worst, in the base system there are Preferences methods for packages absent in the system, for example. The specific preferences instances should be instantiated in these packages, in the ad-hoc initialize class method, or so. Opinion? Querying a Preference instance with a symbol could make Preferences much less cumbersome. Preferences for: #soundsEnabled, Preferences value: #soundsEnabled, etc. Opinion? The perspective is also Preferences used by third-party Application. There is more to write but keep it for later. Hilaire -- <pre class="moz-signature" cols="72">GNU Dr. Geo <a class="moz-txt-link-freetext" href="http://drgeo.eu">http://drgeo.eu</a> <a class="moz-txt-link-freetext" href="http://blog.drgeo.eu">http://blog.drgeo.eu</a></pre> </body> </html>