KDE Core/QtMerge: Difference between revisions
Add links to Qt timezone support bugs |
KDateTime blurb |
||
| Line 6: | Line 6: | ||
===KDateTime vs QDateTime=== | ===KDateTime vs QDateTime=== | ||
KDateTime obtains the current system time zone from KSystemTimeZones::local(), which in turn requires the ktimezoned daemon to update it with any changes to the current system time zone. This would prevent KDateTime from being moved into Qt without modification to this mechanism. Additionally, Qt would need to support Mac OSX and any other operating systems - currently, KSystemTimeZones is only supported on Linux and Windows. Note that all the KTimeZone classes would need to be moved to Qt also in order for KDateTime to work. | |||
If KDateTime were merged into QDateTime, it would probably require source incompatible changes to create a nice API for the combined class. | |||
A more realistic way of merging it into Qt4 would be to add a new class alongside QDateTime. In any case, it might well be desirable to keep QDateTime as a simple class without any time spec (source incompatible change), alongside the merged KDateTime to be used when any time spec was needed. It wouldn't be a good idea to keep QDateTime unchanged in this scenario, since the current QDateTime's time spec property wouldn't play along very nicely with the new KDateTime class's more sophisticated time spec property - having both would lead to unnecessary confusion. | |||
* http://bugreports.qt.nokia.com/browse/QTBUG-10219 | * http://bugreports.qt.nokia.com/browse/QTBUG-10219 | ||
Revision as of 14:11, 16 February 2011
This pages details those KDE classes that are candidates to have some or all of their functionality merged upstream into Qt. Each section will detail what differences exist, why they exist, and what parts can realistically be merged into Qt, and if the changes can be made in Qt4.x or Qt5.
kdelibs/kdecore
KConfig vs QSettings
KDateTime vs QDateTime
KDateTime obtains the current system time zone from KSystemTimeZones::local(), which in turn requires the ktimezoned daemon to update it with any changes to the current system time zone. This would prevent KDateTime from being moved into Qt without modification to this mechanism. Additionally, Qt would need to support Mac OSX and any other operating systems - currently, KSystemTimeZones is only supported on Linux and Windows. Note that all the KTimeZone classes would need to be moved to Qt also in order for KDateTime to work.
If KDateTime were merged into QDateTime, it would probably require source incompatible changes to create a nice API for the combined class.
A more realistic way of merging it into Qt4 would be to add a new class alongside QDateTime. In any case, it might well be desirable to keep QDateTime as a simple class without any time spec (source incompatible change), alongside the merged KDateTime to be used when any time spec was needed. It wouldn't be a good idea to keep QDateTime unchanged in this scenario, since the current QDateTime's time spec property wouldn't play along very nicely with the new KDateTime class's more sophisticated time spec property - having both would lead to unnecessary confusion.
- http://bugreports.qt.nokia.com/browse/QTBUG-10219
- http://bugreports.qt.nokia.com/browse/QTBUG-71
- http://bugreports.qt.nokia.com/browse/QTMOBILITY-1139