[Development] QSettings refactor updates

[Thomas McGuire]

On 13.10.2014 13:46, André Somers wrote:
> Milian Wolff schreef op 11-10-2014 16:44:
>> On Friday 10 October 2014 21:26:11 Tomaz Canabrava wrote:
>>> On Fri, Oct 10, 2014 at 6:35 AM, Milian Wolff <milian.wolff at kdab.com> wrote:
>>>> On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote:
>>>>> Em 10/10/2014 06:18, "Oswald Buddenhagen" <
>>>>>
>>>>> oswald.buddenhagen at theqtcompany.com> escreveu:
>>>>>> On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote:
>>>>>>> may I ask why you don't simply copy KConfig? It's API design has
>>>>>>> proven to be extremely versatile and efficient over the years.
>>>>>> actually, it has proven horrible and is slated for a rewrite for a
>>>>>> decade. the only thing it does right is what tomaz copied to his api.
>>>>> (still sleeping, só I will write better latter)  I used kconfig and I
>>>>> tougth it was terrible to use, that why I came to thiago and hélio
>>>>> Castro
>>>>> asking if I could try a new one.
>>>>>
>>>>> I'll read the emails on this thread and change the code accordingly.
>>>> Please double-check the KConfig API and copy more of its behavior. Some of
>>>> that stuff was also mentioned by Thiago, Bo and Kai:
>>>>
>>>> QConfig("identifier_or_filename"); // this should also be the root group
>>>>
>>>> config.setValue("bla", 123); // would set a global config value, with
>>>> multiple
>>>> overloads or template functions
>>>>
>>>> QConfigGroup group = config.group("something"); // smart handle with
>>>> reference
>>>> semantics
>>>> group.readValue("blub", /* default value */); // read value in group, also
>>>> overloads and/or template function
>>>>
>>>> foreach (QConfigGroup subGroup, group.groups()) // or similar
>>>>
>>>>      qDebug() << subGroup.name();
>>>>
>>>> I still think that KConfig, API-wise, is extremely convenient and haven't
>>>> seen
>>>> anything better so far. The internals and performance is a bit lacking,
>>>> but
>>>> usually not a problem and definitely not related to the API.
>>> It's too error prone regarding typos.
>>>
>>> // main.cpp
>>>
>>> KConfig c;
>>> KConfigGroup g = c.group("blah");
>>> g.setValue("width", 10);
>>>
>>> //  otherfile
>>> Kconfig c;
>>> KConfigGroup g = c.group("blah");
>>> g.value("widht"); // <- no error is issued, this is something that I wanna
>>> have it fixed.
>> How do you intend to fix it? Esp. when looking at what Rafael proposes? If you
>> declare any other class to be used instead of a string, the user can still mix
>> two variables up.
>>
>> I don't see what that has to do with KConfig/QConfig, really.
>>
>> Bye
>
> We're moving away from using these keys directly at all. Instead, we
> only use a real, type safe interface anymore for settings. That is:
> every setting gets a real getter and setter in a Settings class. That
> class is responsible for storing and retreiving the setting from the
> backend (which, in our case, has several levels now). If needed, there
> is not only a getter and a setter, but also a corresponding changed
> signal, but that changed signal currently only works if the setting is
> changed from inside the application itself (good enough for us).
>
> Personally, I think that using string-based key-value pairs (whether the
> key has grouped semantics or not) and then manually casting the value to
> the needed everywhere you need it simply has no place in application
> code in all but the simplist applications. API's need to be type-safe if
> at all possible, and if not, the exposure to the non-type safe API
> should be kept to a minimum. Further more: default values need to be
> consistent. Allowing the application to access the backend from more
> than one place, also means having the specify the default value for
> settings in more than one place. That *will* lead to inconsistencies. In
> our case, that means that there is only one class where there is
> exposure to the non-type safe QVariant-based API of Qt, and that is the
> settings class itself. The rest of the application has no clue, nor
> needs to have any clue, on how the settings are stored: they are just
> using type-safe properties with clearly defined default values.
>
> I would like to see some (modular) kConfig XT-like settings
> specification that results in type save code within Qt though.
> Preferably with a nice editor-plugin inside Creator. Or, perhaps based
> on the Q_PROPERTIES or something similar allowing you to use a default
> getter/setter implementation for simple cases, and add your own for more
> complex ones. That would already save a lot of boilerplate code. I don't
> believe in auto-generating configuration dialogs, though a tree
> representation would be useful for advanced editing and developer settings.

+1, something like KConfigXT that auto-generates QObjects with 
appropriate getters, setters and Q_PROPERTIES would be very useful. Not 
just for type safety - also for exporting settings objects directly to 
the QML world, which otherwise is a lot of boilerplate code to write.

Regards,
Thomas
-- 
Thomas McGuire | thomas.mcguire at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4045 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20141013/1f68b115/attachment.bin>