[Interest] Best practices for settings

[Philipp Kursawe]

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.

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.


On Mon, Nov 18, 2013 at 10:38 AM, Rutledge Shawn
<Shawn.Rutledge at digia.com>wrote:

>
> On 17 Nov 2013, at 2:53 PM, Tim Hoffmann wrote:
>
> > Hi all,
> >
> > Are there any best practices for working with QSettings in larger
> > projects with many settings?
> >
> > In particular:
> > - How do you efficiently synchronize settings with widgets in an options
> > dialog.
> > - How do you efficiently detect changes made in an option dialog. (I
> > have some options that need significant calculations after changing.
> > These should only be triggered if the corresponding setting was actually
> > changed.)
> > - How do you access the settings in the source code? Always casting the
> > QVariants seems a bit tedious but the alternative would be to have
> > additional local variables (or members) for the values which you would
> > have to maintain additionally.
>
> Whenever I used QSettings in widget-based applications, I ended up making
> a subclass for the purpose of having accessors for all the data types that
> the application needed (which can do the variant conversions), and any
> other missing features that the application needed.  You can probably add
> signals and slots too, to make it easier to wire up to various parts of the
> app.
>
> BTW we have settings exposed to Qt Quick now.  If you try it, let us know
> if the API is complete enough to get done what you need to.
>
> http://doc-snapshot.qt-project.org/qdoc/qml-qt-labs-settings-settings.html
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20131118/ed213cad/attachment.html>