Now that I have slept and I reread the patches, I find out that we probably
want a new class KDynamicSetting or something like that.
The purpose of such a class is to contain a single setting (for instance if
the user wants animations or not). As you can see, on most of the private
slots I created on different places on the patches the only thing we need to
do is to update the value of such a property.
The KDynamicSetting could become updated automatically when it receives a
signal from KGlobalSettings::self(), so the app that is reading the setting
is completely unknowing what's going on down there, just reads the property.
On the cases that we also need to do some stuff apart from updating the
variable value (see klineedit.cpp as an example), it is easy: we can add to
the KDynamicSetting [or however we can call it] a signal that is emitted when
its contents have changed. This way, if our app needs to do special stuff for
being consistent at that moment, we can connect our app code to that signal.
What do you think ?
Rafael FernÃndez LÃpez
GPG Fingerprint: B9F4 4730 43F8 FFDD CC5E BA8E 724E 406E 3F01 D070