KConfig and KGlobalSettings (user settings for widgets)

Kevin Ottens ervin at kde.org
Thu Mar 15 22:22:10 UTC 2012


On Tuesday 13 March 2012 22:47:06 David Faure wrote:
> On Tuesday 13 March 2012 22:04:18 Alexander Neundorf wrote:
> > There it is quite similar: do we just provide independent libraries, where
> > every developer can/must take care that the libraries follows KDE
> > conventions  how it is built and installed, or do we provide some common
> > thing everybody uses, and so everything fits together as it should.
> 
> I know that you're struggling with this topic at the moment, but I actually
> think the answer is "it depends".
> 
> At the lowest level, we provide functionality that is completely
> independent: karchive is the best example. No configuration needed there.
> 
> sonnet is also an interesting example: you could have a spellchecker that is
> entirely configured by the application, or a spellchecker that actually
> knows the default language for the current user (which is better
> integration) ... and actually Qt does know the current language(s). So this
> kind of destroys the argument in my previous email... Qt, too, can use user
> settings.
> 
> What's more difficult is when KDE wants more configurability than Qt :-)
> (e.g. "show icons on pushbuttons").
> The Qt solution to such things is more commonly a widget style hint, for
> instance. Heh... wait... oh... it exists already:
> style()->styleHint(QStyle::SH_DialogButtonBox_ButtonsHaveIcons)
> 
> There goes another argument down the drain. This is the proper solution, not
> KGlobalSettings. The widget style that implements this style hint can read
> user settings, that's fine.
> kdeui/kstyle.cpp even does that, calling KGlobalSettings. Bingo :-)

I'd just like to stress and point out that the approach pointed in the two 
problems above is really the one we should strive for. Provide plugins, and 
hints to Qt wherever we can, and through contribution extend those facilities 
when something is missing. It's definitely a cleaner approach than the "let's 
roll another KDE specific class".

(I'm obviously aware we won't succeed everywhere but we should aim high)

> Thanks for making the opposite point, it made me look further into it :)
> I'll fix KPushButton accordingly.
> 
> This is another case where notification isn't needed, the setting is used
> when creating new push buttons.
> 
> To summarize: as discussed before, we want the API to be "standard Qt", and
> the behavior to be "KDE-specific" where appropriate (e.g. respecting the
> settings of the KDE user). With all the "callbacks" in Qt (platform plugin,
> widget style, etc.) it's not impossible to do, even though it's more work
> than simple subclasses (e.g. of widgets), obviously.

+1000

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120315/9529115f/attachment.sig>


More information about the Kde-frameworks-devel mailing list