KConfig and KGlobalSettings (user settings for widgets)

[Alexander Neundorf]

On Tuesday 13 March 2012, David Faure wrote:
> 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.

Yes, I agree. This is one of the points which makes KDE apps (...apps using 
widget from KDE) look and behave consistent. We should keep that.

Is maybe this *the* general KDE frameworks feature:
Every KDE frameworks library has access to the "KDE settings", in order to 
work flawlessly in a "KDE environment" and behave consistent to all other "KDE 
applications" ?

This reminds me very much of the completely-separate-libs vs. somewhat-
integrated-framework issue on the buildsystem side (I'm still working on 
prototypes, but their priority is lower than the cmake work for KDE frameworks 
right now).
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.

Alex