[Cuis-dev] The Preference model

[Juan Vuletich]

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!


> Hi all,
>
> The Preference model in Cuis, to my current knowledge, is composed of 
> two classes: Preference*s* 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:
>
>     * name helpString - symbol name and detailed description
>     * 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.
>     * categoryList - an array of selector describing the categories
>       the preference belongs to. I think one selector is enough.
>       *Opinion?*
>     * 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?*
>
> 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?*
>
>     * DictionaryOfPreferences - Hold the Preference instances.
>     * Parameters - Unclear. *Opinion?*
>
> 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
>
> -- 
> GNU Dr. Geo
> http://drgeo.eu
> http://blog.drgeo.eu


-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
https://twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220427/07191ed0/attachment.htm>