KConfig and KGlobalSettings (user settings for widgets)

[David Faure]

I'm hitting a dilemma, for which I would like some input.

KPushButton and KIconLoader belong in the kwidgets framework (terietor moved 
it there in his branch).

They both need KGlobalSettings (for reading user preferences such as 
showIconsOnPushButtons() and for notification of icon settings changes).
KGlobalSettings uses KConfig for reading these user settings.

KConfig is not yet splitted out. I looked into that, but it depends on 
KStandardDirs, not only internally, but in its API: it takes a char * 
resourceType, which is a KStandardDirs concept, and it takes a KComponentData 
(not only for the component name, but also potentially with customized dirs).

And the plan for KStandardDirs was "layer 4 (if not deprecated) / kde4support 
(if deprecated)" - i.e. not useable by lower-level frameworks, in any case.

I see two solutions out of it, none really great:

A) making KConfig a framework

Not much is happening on the QConfig/dconf side (AFAIK, nothing), so I'm 
thinking it might be a good idea to have a KConfig framework, at least until 
something else comes around.

The problem with this solution is that it requires changing the API: using the 
QStandardPaths enum instead of the KStandardDirs resource type, and an 
optional QString instead of the optional KComponentData. I think that's an 
acceptable porting effort for apps, but it's the wrong way to go if we're 
deprecating KConfig and providing a replacement; in that case keeping the 
current API is better.

B) commenting out KConfig-related code

(in kglobalsettings for now, but surely the same will apply to other places in 
the future). This is the solution that assumes that something better will come 
along before we release KF5.

At this point, this seems to me like a dangerous bet.

Steve was pointing out that my commits removing kcmdlineargs usage with a 
"TODO port to QCommandLineArguments" were similarly "wishful thinking", since 
QCLA doesn't exist yet, but it's a different situation. Laszlo started to do 
some work on it, and I hate kcmdlineargs enough to make a promise here: I'll 
do whatever it takes to get a new command-line args class, even if I have to 
finish it myself, and even if it has to be in kcoreaddons if we can't get into 
Qt, but one way or another we'll have something better.
On the other hand I don't plan on writing QConfig myself, so it's different :-)


PS: to come back to KGlobalSettings. Qt doesn't have user-configurable 
settings, it lets apps decide on such things. But IMHO that's where a line 
gets drawn between "widgets which should go into Qt" and "kwidgets". We don't 
want every app to decide on everything (icon sizes, mouse settings, icons on 
buttons, etc.), so we need KGlobalSettings. The alternative when the settings 
actually exist in Qt, such as QApplication::startDragDistance(), is to let Qt 
get the values from a platform plugin [theme], i.e. have a plugin that reads 
the KDE settings. I like that solution a lot, but it requires that everything 
that's configurable in KDE (e.g. icons on buttons, opaque resizing of 
splitters, ) is made available as Qt API, and it's missing notification of 
changes, for settings which end up being cached (unlike startDragDistance).

--
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5