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

[David Jarvie]

On Wed, February 16, 2011 11:57 am, John Layt wrote:
> 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
> http://community.kde.org/KDE_Core/QtMerge , feel free to add stuff there.
> David Jarvie, could you add something to the KDateTime entry?

Done. I hope it contains enough explanation - if you think it needs more,
please say so.

-- 
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm