Moving stuff upstream

[Stephen Kelly]

John Layt wrote:

> 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?
> 
> Cheers!
> 

I added some links to time zone related bug reports. Surprisingly they seem 
to be moving this week/last week. I say surprisingly because they other day 
a troll claimed nobody asks for it. It could just be some left hand/right 
hand stuff I think.


<steveire> ddenis: Are you also working on timezone handling in QLocale?
<steveire> AFAIU that's the reason we have KDateTime instead of QDateTime
<ddenis> steveire: eeeeewww, no :)
<ddenis> steveire: we have briefly talked about timezone info for 
Qt/QLocale, but didn't come to any conclusion. And nobody asks for it as far 
as I know
<steveire> I do :)
-*- jlayt thinks there's a lot of parts of QLocale and QDateTime that need 
improving before KDE could consider using them
<steveire> I'm sure I've seen people ask for it on qt intereset and on a bug 
asking for it
<steveire> jlayt: Agreed. The hard part is convincing nqdf that KDE wanting 
equates to 'people wanting it' though :)
<ddenis> yeah. But KDE provides lots of things that will never become part 
of Qt (for example setters in KLocale)
<steveire> Yeah. My motivation is getting the actual functionality in Qt so 
that we can use Qt APIs like QDateTime in our APIs instead of subclassing 
and requiring to use KDateTime in our APIs, thereby making KDE libraries 
incompatible with Qt.
<steveire> Extra setters and convenience methods don't *have* to be in 
subclasses.
<steveire>  just want to get KReplacementClass out of the APIs and get the 
functionality through a different design.
<steveire> Part of that is getting timezone support in Qt.
<jlayt> ddenis: agreed setters don't belong in QLocale, but we can take care 
of that ourselves, but I would like to have QLocale support getting / 
formatting all the features available on all platforms, it would save me a 
lot of work :-)
<ddenis> jlayt: I don't see it happening :( For example - currency - KLocale 
just provides too much - we _can_ put it all to Qt, but it will take too 
much effort with no clear benefit - nobody asking for that. People are 
asking us to provide a way to format money (number to string), nothing more

I can understand nqdf not wanting a code dump from KDE and not wanting to 
support all of the features KDE does to the extent KDE does, but there's 
still a lot that could be done in QClasses to enable the broader features 
required in KClasses.

All the best,

Steve.