[Interest] Best practices for settings
phil.kursawe at gmail.com
Mon Nov 18 12:33:24 CET 2013
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
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:
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
> 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.
> Interest mailing list
> Interest at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest