[Interest] Best practices for settings

André Somers andre at familiesomers.nl
Mon Nov 18 12:45:30 CET 2013

Philipp Kursawe schreef op 18-11-2013 12:33:
> I am also currently struggling how to wire up changes to QSettings 
> with the lack of signals/slots. Some of my plugins depend on global 
> app settings but with QSettings its impossible for them to get 
> notified about changes in settings.
> I thought subclassing QSettings is a good idea, until I found it it 
> does not use virtual functions I could overload.
I often see with OO programmers that they very quickly turn to 
subclassing to use a class they find useful. Somehow, encapsulation 
doesn't seem to get the same amount of attention as inheritance does. 
Inheritance is not the tool to use here, I think.

> Another problem, unsolved as of yet: How do I expose potential 
> settings to the UI. I thought about a meta-data driven way where all 
> an QObjects settings are composed of its Q_PROPERTY's. Since not all 
> properties are meant to be configured via UI, you could annotate some 
> using a class property like "no-setting" as a comma separated list of 
> property names that are not configurable. To group certain properties 
> in a group you could also use a class property like:
> Q_CLASS_INFO("setting-group-server", "hostName,port,login,password")
> The UI would then fetch the id based translation for 
> "setting-group-server" and display the settings specified in a group box.
Auto-generated UI's generally suck. They are not layed out in a nice 
way. They cannot take conceptual relationships between items into 
account. If you're going to hand-craft your UI for your settings anyway, 
you don't need a setup like you describe either.

However, you might be interested in KConfig_XT[1], which is KDE's 
solution to the problem. It defines settings in XML, which gets compiled 
into source code.


[1] http://techbase.kde.org/Development/Tutorials/Using_KConfig_XT

More information about the Interest mailing list