KDynamicSetting new class proposal

Matt Rogers mattr at kde.org
Sun Feb 10 16:35:52 GMT 2008


On Sunday 10 February 2008 09:35:23 am Rafael Fernández López wrote:
> 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 ?
>

You need to find two apps that are using it in its current form before I'll 
even entertain putting this in kdelibs.
--
Matt
-------------- 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/26b8ee2b/attachment.sig>


More information about the kde-core-devel mailing list