[Cuis-dev] The Preference model

[Gerald Klix]

Hi Guys,

I have two (or three) wishes if we redesign the preferences system.

1. Move the class-side code in Preferences to the instance-side by using
a preferences singleton. This way we can easily change a whole set of
preferences, maybe loading from disk.
2. If you add some meta/type-information, do this in a general manner.
There are obvious other uses for such a system.  

Not so important:
3. Make the type/meta information optional eg. a package.
There is little use of having the meta information in the image,
once you have a set of working personal preferences.
If you use Cuis to implement daemons, you probably set some preferences
with a script and don't need a type system.


Just my 0.50€,

Gerald


On 4/27/22 21:03, Juan Vuletich via Cuis-dev wrote:
> 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
>  
>  
>