Jump to content

KDE Core/QtMerge: Difference between revisions

From KDE Community Wiki
Jlayt (talk | contribs)
Jlayt (talk | contribs)
Line 33: Line 33:
** get/set/format by Era
** get/set/format by Era
** rfc dates
** rfc dates
** narrow name formats
** short year window
** short year window
** day periods (extends am/pm)
** day periods (extends am/pm)

Revision as of 15:58, 13 May 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

  • KConfig allows different backends.
  • KConfig provides kiosk.

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 better way of merging KDateTime into Qt4 would be to add a new class alongside QDateTime. QDateTime would be kept 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.

Other missing features:

  • QTimeDuration
  • QTimeRange

KLocalizedDate & KCalendarSystem vs QDate

KDE provides the following features which Qt does not:

  • Calendar Systems
  • More date component and format options
    • get/set/format by ISO Week
    • get/set/format by Ordinal Date (day of year)
    • get/set/format by Era
    • rfc dates
    • short year window
    • day periods (extends am/pm)
  • more date math options
    • ymd difference
  • alternative week number systems

Qt has the following problems KDE would like to see resolved:

  • jd is stored in a uint preventing dates before 4715 BC, when using an int would allow a more useful date range
  • jd 0 is used to mean invalid when it is actually a valid date, change to have
  • important code is inline and no d-> means impossible to change implementation without breaking BC, this should be fixed
  • poor overflow checking in places returns incorrect results instead of an invalid date
  • doesn't support full set of format options from Unicode spec

KLocale vs QLocale

KDE provides the following features which QLocale does not:

  • Ability to set formats
  • Language preference list
  • Digit Sets
  • Digit Grouping
  • Currency Codes
  • Binary size units / format byte size
  • format duration
  • pretty formats
  • calendar systems
  • posix and unicode formatting
  • more flexible date/time formatting
  • day periods (am/pm)
  • week start
  • working week
  • religious observance
  • week number systems
  • country subdivisions
  • iso codes

Other desirable features:

  • Split/grouped locales, i.e. en_US for money but pt_BR for dates
  • Percentage format (in Qt not KDE)

KIcon vs QIcon

  • KIcon provides access to the installed icon theme.

KUrl vs QUrl

KPluginLoader vs QPluginLoader

  • KPluginLoader enables dynamic plugin loading using desktop-files (e.g. deferred plugin loading on demand in Calligra).