<div dir="auto"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)">Hilaire, thanks for taking the time to write about this and bringing it up for discussion. I’ll share some opinions from the top of my head, see bellow:</span><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 27 Apr 2022 at 12:49 AM Hilaire Fernandes via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div text="#000000" bgcolor="#FFFFFF">
<ul><li>categoryList - an array of selector describing the categories
the preference belongs to. I think one selector is enough. <b style="border-color:rgb(255,255,255)">Opinion?</b><br></li></ul></div></blockquote><div dir="auto">Yes, just one category for a preference sounds better, I wonder what was the reason for allowing a preference to have multiple categories..</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div text="#000000" bgcolor="#FFFFFF"><ul dir="auto"><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. <b style="border-color:rgb(255,255,255)">Opinion?</b><br></li>
</ul>
<p></p></div></blockquote><div dir="auto">Yes, makes sense.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div text="#000000" bgcolor="#FFFFFF"><p dir="auto">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.</p></div></blockquote><div dir="auto"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)">I agree with Mariano that a Symbol for the type should be enough, I’d prefer to make it as simple as possible without creating lots of new clases. </span><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div text="#000000" bgcolor="#FFFFFF"><p dir="auto"><b style="border-color:rgb(255,255,255)">Preferences. </b>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. <b style="border-color:rgb(255,255,255)">Opinion?</b><br></p>
<ul>
<li>DictionaryOfPreferences - Hold the Preference instances.<br>
</li>
<li>Parameters - Unclear. <b>Opinion?</b></li></ul></div></blockquote><div dir="auto">PreferencesDictionary sounds better for a class name. I think it could have exactly the same accessing protocol as a Dictionary (at:, at:put:, at:ifAbsent:, at:ifAbsentPut:, etc), and internally store a Dictionary of instances of Preference by preference name. So instead of the Preferences class we could have an instance of PrefrencesDictionary called #Preferences right?</div><div dir="auto"><br></div><div dir="auto"><blockquote class="gmail_quote" style="width:592px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-color:rgb(0,0,0) rgb(0,0,0) rgb(0,0,0) rgb(204,204,204);color:rgb(0,0,0)"><div text="#000000" bgcolor="#FFFFFF" style="border-color:rgb(0,0,0)"><p dir="auto" style="border-color:rgb(0,0,0)"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)">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. </span><b style="border-color:rgb(255,255,255);color:rgb(0,0,0)">Opinion?</b><br></p></div></blockquote></div><div dir="auto"><br></div><div dir="auto">Yes, packages could register new preferences, and they could do it be instantiating a Preference and registering in Preferences (something like Preferences add: aPreference) or sending a message to Preferences with all the data to instantiate and add a new preference (something like Preferences add: #soundsEnabled type: #boolean category: ‘system-sound’ defaultValue: true).<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div text="#000000" bgcolor="#FFFFFF"><p dir="auto">Querying a Preference instance with a symbol could make
Preferences much less cumbersome. Preferences for: #soundsEnabled,
Preferences value: #soundsEnabled, etc. <b style="border-color:rgb(255,255,255)">Opinion?</b></p></div></blockquote><div dir="auto">I would just use Dictionary semantics for querying preference values like Prefeences at: #soundsEnabled. And for getting the actual Preference instance similar to #associationAt: in Dictionary I would use #preferenceAt: and #preferenceAt:ifAbsent:.</div><div dir="auto"><br></div><div dir="auto">Let’s keep discussing and thinking!</div></div></div>