> 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.
As you say, this would not allow to participants to know which setting changed, only that some settings changed. Under Win32 there is a way to monitor registry changes, yes. But what of you are using ini files, as we do? Of course we could make the policy, that whoever changes a setting needs to post an event to QApplication.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
