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.
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 QConfFileSettingsPrivate::syncConfFile is in a position to emit signals for each changed property, it doesn't.) Whereas I think Windows has a more fine-grained way of notifying about registry changes. So you could argue that Qt should abstract it… but adding features to QSettings (or even fixing bugs) is unpopular because of its design flaws. The biggest problem is that the API is stateful, with begin/end setters to control which section you are looking at, etc. That can also be fixed in your subclass or wrapper, at a cost in performance: pass the section name to each accessor, so the accessor will do the beginGroup, read/write setting, endGroup. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
