[Development] QConfig update.

Mathias Hasselmann mathias at taschenorakel.de
Thu Oct 16 10:00:13 CEST 2014



Am 14.10.2014 um 18:44 schrieb Tomaz Canabrava:
> On Tue, Oct 14, 2014 at 1:35 PM, Milian Wolff <milian.wolff at kdab.com
>  <mailto:milian.wolff at kdab.com>> wrote:
>
>> On Tuesday 14 October 2014 13:22:51 Tomaz Canabrava wrote:
>>> QConfig and QConfigGroup *does not* support setting a default value
>>> on the getter, I know that this is used in a lot of places but this
>>> can cause inconsistencies:
>>>
>>> Main.cpp
>>>
>>> QConfig c; c.value("window-width", 800);
>>>
>>> MainWindow.cpp c.value("window-width", 1200);
>>>
>>> so we must create a better way for that. for now, I simply removed
>>> the possibility for that, we can only do

I can imagine use cases where I'd like to have this flexibility. The 
best default value for an unspecified setting very much can depend on 
the context.

>> Imo, this makes this API extremely inconvenient. Yes it's possible to
>> do an error, but that is life. You should only add such
>> error-prevention stuff into the high-level schema stuff, not into
>> QConfig itself.

I very much agree.

> Since I wanted to add schema-validation on the low level stuff, this
> wouldn't be an issue, 'value couldn't be read' would cause an assert.
> but I can postpone this for later.

I don't think it is wise to unconditionally crash programs for things
that just during normal usage. With this string based API those settings 
schema and the actually accessing code are only losely coupled. So it 
will just happen that applications built for version A of the settings 
schema will access a configuration written with version B of the schema 
in mind. Because of program upgrades. Because the user has two versions 
of the same program installed. Because of human mistakes. Such 
situations must be handled gracefully: Users just don't like their 
programs crashing and maybe never starting again (without deleting 
various files). What's your graceful error handling plan for schema 
mismatches?

Ciao,
Mathias



More information about the Development mailing list