Moving stuff upstream (was: A Qt replacement for KGlobal::ref and deref)

Stephen Kelly steveire at
Wed Feb 16 22:06:13 GMT 2011

John Layt wrote:

> On Monday 14 February 2011 22:35:13 Stephen Kelly wrote:
>> You might think in terms of how much a typical KDE application ends up
>> using, but I'm thinking in terms of how much a typical Qt application
>> ends up using. Gregory is not going to end up using KLocale KConfig
>> KDateTime etc just because he wants to use kimap. I'm thinking in terms
>> of the Qt community and broader appeal - the people I interact with on
>> qt-interest, not the KDE community.
> The thing is, most of what is in kdecore date classes really does belong
> in the Qt classes, these are standard things on all platforms that Qt just
> hasn't
> implemented.  QLocale is bizarrely incomplete in places.  Why wouldn't Qt
> want
> to handle timezones correctly in this global internet age?  Why wouldn't
> they
> want to format dates correctly?  Why wouldn't Qt want to support what the
> system localisation settings actually are?  Some of this can actually be
> fixed in Qt 4.x, we just need to convince Qt to accept the patches.

sebsauer has pointed out to me several times that QtMobility has a lot of 
useful stuff in it, including handling mimetypes (possible replacement of 
the kmimetype stuff?). I also note that the Qt time zone stuff is getting 
moved along because of the needs of Qt mobility. I conclude that stuff which 
QtMobility needs in Qt get added to Qt, and those things allow QtMobilty to 
implement a platform. KDE does not hold that sway. Perhaps it's time to 
'align the goals and requirements of QtMobility with those of KDE'. 

> KLocale is something that we need to take a step back from and ask why we
> have
> it and if there isn't a better more standard way to achieve those things. 
> We have it so our users can customise their locale settings, to add some
> non- standard settings, and so apps can change the settings temporarily to
> do
> clever things.  I've some ideas on how we can do those better.
> Remove KLocale and the date classes from the core (non-ui) stack and a lot
> of problems disappear, including their dependency on KConfig.
> KConfig is going to be the big problem, fortunately not one I deal with
> :-) Perhaps a KConfig backend to read/write from QSettings files would
> remove most
> Qt-only objections to using it in things like kimap?  I'd hate to see us
> have to ifdef support for two config systems in such libraries.

I agree that ifdefs shouldn't be used/needed. In extreme cases we can define 
an interface to KThing and QThing and have the KThing implementation up on 
the platform level. Proof of this concept here:

Although for a config system, I don't think a solution like that would work 
in the same way.

I think the real problem is mixed responsibilities of classes and libraries 
in kde{,pim}libs. kconfig is respsonible for the file format as well as 
de/serializing the data into strings/numbers/bools/dates/whatever. That's an 
obvious responsibility of a config system, and it doesn't sound platformy.

However, kconfig is also responsible for knowing where the actual data files 
should be, so it depends on KStandardDirs (platformy no doubt). That, 
through other interdependencies means that it has the runtime dependencies 
on daemons like ktimezoned etc. It doesn't have to be like that. 

Could the way to find where the actual files are could be a QStringList, 
which is then supplied through the Hollywood principle (don't call us, we'll 
call you):

instead of (pseudocode)

(somewhere in kconfig)

have something like:

The KConfig returned by KGlobal (which would also be in the platformy tier) 
would be pre-setup with this.

Or a bit of a virtual interface could be used instead of Hollywood.

The point is that there are many ways of separating functionality from 
platform, and it all comes down to what you've heard to be a good idea a 
million times: separating responsiblities.



More information about the kde-core-devel mailing list