[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.
André
More information about the Development
mailing list