<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Folks, Apologies for not getting more involved in this discussion. I think Preferences need a good rethinking. Please feel free to discard all that is currently there! I'm sure the community will come up with a better design that the current one. While you are all at this, I'm pretty sure that many of the existing preferences are not worth keeping, and replacing them in senders with the default behavior is totally ok. No one wants to browse hundreds of useless preferences to find the few that really make sense. Feel free to discard anything! Thanks a lot! <blockquote cite="mid:22630e44-3ab9-b388-dab7-5fc8d7356e75@drgeo.eu" type="cite"> 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>GNU Dr. Geo <a moz-do-not-send="true" href="http://drgeo.eu">http://drgeo.eu</a> <a moz-do-not-send="true" href="http://blog.drgeo.eu">http://blog.drgeo.eu</a></pre> <pre wrap=""></pre> </blockquote> <pre class="moz-signature" cols="72">-- Juan Vuletich <a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a> <a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a> <a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a> <a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a> <a class="moz-txt-link-freetext" href="https://independent.academia.edu/JuanVuletich">https://independent.academia.edu/JuanVuletich</a> <a class="moz-txt-link-freetext" href="https://www.researchgate.net/profile/Juan-Vuletich">https://www.researchgate.net/profile/Juan-Vuletich</a> <a class="moz-txt-link-freetext" href="https://patents.justia.com/inventor/juan-manuel-vuletich">https://patents.justia.com/inventor/juan-manuel-vuletich</a> <a class="moz-txt-link-freetext" href="https://twitter.com/JuanVuletich">https://twitter.com/JuanVuletich</a></pre> </body> </html>