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

John Layt johnlayt at
Wed Feb 16 11:57:03 GMT 2011

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.

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.

Anyway, I've started a page to document such things at , feel free to add stuff there.  
David Jarvie, could you add something to the KDateTime entry?



More information about the kde-core-devel mailing list