KDynamicSetting new class proposal

[Rafael Fernández López]

Hi all,

I've locally added this class to kdelibs/kdeui/kernel folder. I would like to 
know what you think about it.

As you know, I've been working on the "global animation" switch. It has 
presented some "problems" to me, as for instance, having to make more dirty 
the code of the other libraries/applications by having to connect to 
KGlobalSettings::settingsChanged(int) signal. This is not comfortable.

The most part of this code the only thing they did at the slot was just update 
the property. On others (as for instance, KLineEdit) it was needed to do 
extra stuff (as updating qtimelines for they to be correct if suddenly the 
animations are switched again).

KDynamicSetting contains a QVariant, which contains the property that is 
important to us. So you do:

KDynamicSetting *anims = new 
KDynamicSetting(KDynamicSetting::animationsEnabled);

and now on your code you can freely check for "anims.content().toBool()".

If you need to do extra stuff, for instance update a status bar that 
says "Animations: enabled|disabled", you can do something like:

connect(anims, SIGNAL(settingChanged(QVariant, KDynamicSetting*)), this 
SLOT(updateStatusBar()));

There is a nice thing also, only the properties that were actually updated 
emits the signal. It internally checks if the contents have changed, and only 
in that case the signal is emitted.

Why a new class

Well, this has been a discussion mainly from Nick Shaforostoff and me at my 
blog (www.ereslibre.es). I have right now finished the template of what this 
class can be, and I hadn't got material to send a serious mail to kcd. Anyway 
I already talked about this before on other mail (with subject: "Re: [PATCH] 
Builtin animations (dis)(en)abling", sent 9, february, 2008).

Now the answer. I guess what we all want is keep KGlobalSettings as clean as 
possible. Implementing an internal cache for this didn't make sense to me, 
because there are lots of apps that only call these methods on the load time, 
and filling a cache for only one time is not worth it. Other cache policies 
have also problems, and only contribute to make KGlobalSettings bigger and 
heavier.

So, that's the reason of why I had chosen to write a new class instead of 
writing a transparent cache or something similar.

What will use it

For now, my patch on animations can wait. If this class is approved to get in 
kdelibs, then the patch could be reconverted to use this class, it will take 
me 15 min when this class is into kdelibs (if it gets in).

Peter Penz an me also had a discussion some time ago on how to obey user 
settings on fonts for our listviews. I guess we could use this class in there 
(Dolphin) with some other details on settings policies that don't proceed to 
be discussed here.

Summing up

KDynamicSetting represents a single setting that can change on the runtime 
because of global changes (e.g. systemsettings changes) and that are out of 
QApplication reach (e.g. setFont, setPalette, ...).

Aside note

Probably there are some settings that can be removed on the attached files. 
Some of them has been added to show how easy would be to extend this class to 
new needs. If this gets into kdelibs I would be happy for now with: 
invalidSetting, generalFont [dolphin discussion], showIconsOnPushButtons and 
animationsEnabled.

So, comments, suggestions ?


Bye and thanks,
Rafael Fernández López

GPG Fingerprint: B9F4 4730 43F8 FFDD CC5E BA8E 724E 406E 3F01 D070
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdynamicsetting.h
Type: text/x-c++hdr
Size: 2977 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080210/7e07607e/attachment.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdynamicsetting.cpp
Type: text/x-c++src
Size: 5278 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080210/7e07607e/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080210/7e07607e/attachment.sig>