Re: [Interest] Best practices for settings

Philipp Kursawe schreef op 18-11-2013 13:25: On Mon, Nov 18, 2013 at 12:45 PM, André Somers > wrote: 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 g

Re: [Interest] Best practices for settings

> The mechanism to be notified would be different depending on where the settings are stored. E.g. if they are stored in a file, you could try using a QFileSystemWatcher (although I haven't tried that myself), but you still wouldn't know > which setting changed. (Although maybe QConfFileSettingsP

Re: [Interest] Best practices for settings

On Mon, Nov 18, 2013 at 12:45 PM, André Somers wrote: > 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

Re: [Interest] Best practices for settings

On 18 Nov 2013, at 12:33 PM, Philipp Kursawe wrote: > 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.

Re: [Interest] Best practices for settings

Or the best thing for Linux + QML - use Qt GSettings binding https://launchpad.net/gsettings-qt :) 2013/11/18 Mandeep Sandhu : > On Mon, Nov 18, 2013 at 5:24 PM, André Somers wrote: >> Tomasz Siekierda schreef op 17-11-2013 17:29: >>> The settings class is a Singleton, and all options are accesib

Re: [Interest] Best practices for settings

On Mon, Nov 18, 2013 at 5:24 PM, André Somers wrote: > Tomasz Siekierda schreef op 17-11-2013 17:29: >> 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 Singleto

Re: [Interest] Best practices for settings

Tomasz Siekierda schreef op 17-11-2013 17:29: > 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 t

Re: [Interest] Best practices for settings

On Mon, Nov 18, 2013 at 5:03 PM, Philipp Kursawe wrote: > 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.

Re: [Interest] Best practices for settings

Hi Tim, Tim Hoffmann schreef op 17-11-2013 14:53: > 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

Re: [Interest] Best practices for settings

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 thoug

Re: [Interest] Best practices for settings

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

Re: [Interest] Best practices for settings

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 det

Re: [Interest] Best practices for settings

Den 17-11-2013 17:29, Tomasz Siekierda skrev: > As said: getters and setters:) Add a signal to inform about changes to one of the settings plus declare each setting with Q_PROPERTY, and we're there. Bo. -- Bo Thorsen, European Engineering Manager, ICS Integrated Computer Solutions. Delivering W

Re: [Interest] Best practices for settings

On 11/17/2013 9:29 AM, Tomasz Siekierda wrote: > On 17 November 2013 14:53, Tim Hoffmann 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 pro

Re: [Interest] Best practices for settings

On 17 November 2013 21:53, 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 ch

Re: [Interest] Best practices for settings

On 17 November 2013 14:53, Tim Hoffmann wrote: > Hi all, Hi > 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:

[Interest] Best practices for settings

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 nee