[Development] QSettings refactor updates

André Somers andre at familiesomers.nl
Mon Oct 13 13:46:21 CEST 2014

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.


More information about the Development mailing list