Moving stuff upstream (was: A Qt replacement for KGlobal::ref and deref)
steveire at gmail.com
Wed Feb 16 22:21:32 GMT 2011
David Jarvie 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?
> Done. I hope it contains enough explanation - if you think it needs more,
> please say so.
I'm not sure the intention should be a wholesale merge of KDateTime into
QDateTime or something similar to that. Some of the features and APIs in
KThing classes are a direct result of being outside of the Qt APIs. I think
the question should be:
What is the minimum of changes needed to QDateTime such that it can be used
as a data transfer class by KDE?
Currently as far as I know, QDateTime simply strips any timezone
information, so that's a must. I'm not very familiar with KDateTime but
looking at the API, the rest is comparators (we could have a
KDateTimeComparator), time delta (daysTo, potentially replacible with
http://qt.gitorious.org/qt/qt/merge_requests/1014), and different formats
Or all that stuff could stay in a class called KDateTime, but be repurposed
not to be a data transfer class of datetime+timezone info, but a features,
functionality and convenience class. If KDateTime were no longer a data
transfer class we could use QDateTime in our APIs instead of KDateTime,
which would mean our APIs would be compatible with other Qt APIs and
therefore usable together.
The QDateTime + timezone stuff is in motion right now, so it's a chance to
see if it can suit the needs of KDE and not just QtMobility. If you have
extra input I'd encourage you to make it on that bug report.
More information about the kde-core-devel