[Interest] Best practices for settings

[Bob Hood]

On 11/17/2013 9:29 AM, Tomasz Siekierda wrote:
> On 17 November 2013 14:53, Tim Hoffmann <thoffmann at texstudio.org> wrote:
>> Are there any best practices for working with QSettings in larger
>> projects with many settings?
> I'm not claiming the ones I will list are "the best", but they do work
> quite well in several projects I'm involved in.
>
>> In particular:
>> - How do you efficiently synchronize settings with widgets in an options
>> dialog.
> The settings class is a Singleton, and all options are accesible
> through member variables (private + getters and setters, or public -
> if you prefer). Although I personally believe Singletons are evil,
> they can be useful - and this is one of the place where the benefits
> outweight the problems.
>
>> - 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.)
> The settings class stores everything through members, with
> corresponding getters and setters. So in your dialog, you just need to
> check if the value is the same as the one returned by the getter.
>
>> - 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.
> As said: getters and setters :)

I too use a mechanism that is similar to what sierdzio has described.  I use a
Singleton (usually called Config).  I, however, tend not to use QSettings, but
rather keep my application settings in XML files.  As such, my Singleton
maintains an internal XML DOM document from which it serves and updates the
settings via setters/getters, as well as a read-only operator[] access.  There
is also a clear() method provided for removing a setting.

The input/output values for the class are QVariants.

The Config Singleton doesn't actually keep track of what has changed and what
hasn't.  It just dumps the entire DOM document back to disc when ordered
(usually in the destructor of the application class).

As with sierdzio, this is my "personal best practice".  YMMV.  ;)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20131117/fc6636e1/attachment.html>