[Development] QConfig update.

André Somers andre at familiesomers.nl
Wed Oct 15 10:02:59 CEST 2014

Milian Wolff schreef op 14-10-2014 18:35:
>> 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
>> c.value("window-width");
> And how do you check whether window-width was read or not? What do you return
> on error? A default-constructed value? What type does the value have for that
> matter?
> 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.
> Without the ability to provide a default value, one can never figure out
> whether `c.value("some-int") == 0` means the value could not be read and a
> default should be used, or whether the value is 0.
Indeed. I think default values are vital, even if the issue you (Tomaz) 
point out is valid like I argued yesterday. That is why we only use 
QSettings anymore from within our own type-safe settings class.

>> I plan to set the defaults via a schema-based file ( could be the KConfigXt
>> based, but I dislike having to edit XML by hand, so something more similar
>> to QML would be best ).
>> Any tougths on that?
> If you store JSON, maybe use JSON? The mapping will give you the default value
> and from there you get a type.
> {
> "foo" : 1,
> "bar" : { "lala": "string" }
> }
XML hand-editing is of course not needed. If XML would be used (like it 
is for .ui files and .rcc files in Qt), an editor for this type can be 
added to Creator. That would get rid of the need to hand-edit XML files.

JSON could also work of course. Perhaps it is important however to first 
have a clear goal on use cases the schema has to solve, before going 
into a file format for it. To me, some requirements would be:
1) Easy generation of type-save settings class
2) Management of default values
3) Capable of handling custom types, including enums
4) Makes it easy to avoid writing boilerplate getters and setters, but 
possible to do so if needed
5) Also generates changed signals

Furthermore, I'd like to have the ability to have more than one of 
these. That is: we are in a large project with several libraries. These 
libraries need to access part of the settings. The overall application 
needs to access the whole settings structure of course (for instance for 
showing a settings dialog), preferably in some nice unified way.

I think settings resemble properties to a very large extend. Perhaps it 
would, as an alternative to the XML or JSON schemes already suggested, 
but possible to build on the Qt property system instead for this. It is 
familiar to developers, does not require a special editor, and allows 
for using your own code instead of generated boilerplate quite naturally 
(point 4 above). Perhaps something like:

class AppSettings: public QTypedConfig
    Q_SETTINGS(); // Q_OBJECT, but perhaps with some extra's like the 
ability to include generated function declarations for getters and setters

    Q_SETTING(int width SETTING "dialog/window-width"  DEFAULT 800); 
//use generated getter, setter and notify
    Q_SETTING(MyCustomType myValue READ myValue  WRITE setMyValue NOTIFY 
myValueChanged); //use custom getter and setter

     AppSettings(QObject* parent = 0);

     MyCustomType myValue() const;
     void setMyValue(const MyCustomType& value);
     Q_SIGNAL void myValueChanged(const MyCustomValue& value);



More information about the Development mailing list