[Cuis-dev] [Preference] Category as domain name

[Luciano Notarfrancesco]

Hi Hilaire,
I’m not sure if we should rename PreferenceNG to PrefernceDictionary, or if
it’s best to keep it. If you get rid of the PrefernceNG class you’d have to
implement PreferenceDictionary with multiple instance variables with
dictionaries to hold preference types, names, values and categories, or a
single dictionary with arrays {name. type. category. value}, etc… there are
several possibilities for the implementation if you do this. On the other
hand, if you keep PreferenceNG and create a new class PreferenceDictionary,
the PreferenceDictionary can have a single instance variable (say
‘contents’ for example) with a dictionary name -> aPreferenceNG, and you
would only need to move the class-side methods from PreferenceNG to the
instance side of PreferenceDictionary.

On Sun, 19 Jun 2022 at 9:44 PM Hilaire Fernandes via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Okay, so all in all we rename PreferenceNG to PreferenceDictionary (to be
> done later anyway) and turn ThePreferences class variable to an instance
> variable?
>
> The system specific methods should be on the instance side as this will be
> where is the dictionary of preference). The way to access the preferences
> will be done instance side versus class side.
>
> The downside: Application preference will have access to methods related
> to system preferences.
>
>
>
> Le 19/06/2022 à 16:20, Luciano Notarfrancesco a écrit :
>
> I would put them in PreferencesDictionary class side and call them to
> initialize the global Preferences.
>
> On Sun, 19 Jun 2022 at 9:07 PM Hilaire Fernandes via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> Hi Luciano,
>>
>> Okay I had doubt on that.
>>
>> Observe in PreferenceNG there are several class methods to install the
>> system preferences (look at class categories class initialization, data,
>> event handlers, fonts. Where will you move these ones?
>>
>> Hilaire
>> Le 19/06/2022 à 15:58, Luciano Notarfrancesco a écrit :
>>
>> Hi Hilaire, actually I was proposing to move the class side of
>> PreferenceNG to a new class PreferenceDictionary, and then make a global
>> Preferences just an instance of PreferenceDictionary (Smalltalk at:
>> #Preferences put: PreferenceDictionary new). I don’t see the need for an
>> extra singleton class. Also, a tool to view and edit preferences could work
>> on any instance of PreferenceDictionary, maybe even on a list of instances
>> of PreferenceDictionary if that makes sense in your UI design.
>>
>> --
> GNU Dr. Geohttp://drgeo.euhttp://blog.drgeo.eu
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220622/44c5a6d8/attachment.htm>