[Cuis-dev] The Preference model

[Hilaire Fernandes]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220426/c1c3baa9/attachment.htm>