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.
André
[1] http://techbase.kde.org/Development/Tutorials/Using_KConfig_XT
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
