<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi Juan & al., I need to distract you from your current occupation and to take a look at the PreferenceNG implementation. The implementation of PreferenceNG is mostly done. Only the FileList preference needs some attention but it can be done later. Its model was collaboratively designed, but I took alone decision on implementation details, so it may need some review. I can sum up a few key points: <ul> <li>The expected way to access a preference is PreferenceNG at: #guiElementsSize. One can use PreferenceNG guiElementsSize but it will go through a DNU so not really optimal. There is no added-preference-accessor-on-the-fly as in the legacy Preference system, it makes the class ridiculously verbose. External package will need to adjust the way to access a preference. When the preference type is a BlockClosure without argument, #value returns the value of the block. </li> <li>The Preference really focus on storing preference data. Behavior have to be somewhere else or implemented as event handler when a preference value is changed.</li> <li>There is no parameter any more, it is preference too. </li> <li>To create/edit and record a preference: </li> <ul> <li>PreferenceNG name: nameSymbol description: aString category: categorySymbol type: aType value: aValue</li> <li>PreferenceNG name: nameSymbol category: categorySymbol value: aValue (the type is then auto-detected) </li> <li>the preference is auto-kept </li> <li>when the user creates an existing preference, it will update all its attributes but its type and returns it </li> <li>To just edit a preference value, the counter part is PreferenceNG at: #guiElementsSize put: #smallFonts</li> </ul> <li>the method category 'data' contains most of the default preferences, there are all instantiated at the initialization of the class, see 'class initialization' category. I extended the data array with two optional data: type (can be nil for auto-detect) and eventHandler. The later will make PreferenceNG to listen to the #preferenceChanged event of this preference. This is needed for a few Cuis preferences (font change, etc), check the method category 'event handlers'. The data are spread in 4 categories and methods #font #gui #programming and #system</li> <li>A preference defined as a computation of other preferences is implemented as BlockClosure type. I can't integrate them in the data array, otherwise I will have to use dynamic array. As for now, there are instantiated in their own methods in 'class initialization'. </li> <li>Preferences can be saved individually, by category or all. When loaded, it merges with existing preference if necessary </li> </ul> I strongly encourage you and other to take a look at the implementation of the points I emphasized above. For the integration of the class, once we have settled down its implementation, I propose you add the class as is, then I will integrate its use by switching the use of Preferences to PreferenceNG. I will proceed one preference category at a time and send you the associated change set. It will give use the time to do it slowly step by step. Once all the integration is done, with appropriate testing, we can remove the Preferences and Preference classes, then rename PreferenceNG to Preference or Preferences. The latter name will give some level of compatibility for external package accessing preferences, but it will install the bad behavior of accessing preference value by unary message send. Thanks to read until here this long message Hilaire -- 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> </body> </html>