KDE Core/Platform 11/Eliminating Duplication With Qt

Team Members

Olivier, Volker,John, Helios, Ishmail.

Post-it Notes

• Merge, Augment, Kill
• Small changes in Qt to improve KDE contributions
• How can we get mindset change in KDE towards Qt
• Bigger things like Printing, QDateTime, maintainerships
• Fixing QUrl so that KUrl is not necessary
• Replacing QSettings with KConfig DConf? Kiosk?
• KAction - Add default shortcut to QAction, global shortcuts
• KLocale - Move to Qt
• tr / i18n - gettext, script, KLocalizedString - move to Qt

Notes

Kconfig / QSettings / DConf - No-one felt qualified to discuss this, needs a separate break-out group

• A Good Thing (TM), let's do it
• Freeze kdelibs4, but not too hard may need changes or can backport some KDE5 stuff
• Must start now to get what we need into Qt5 or will miss the chance
• Not everything needs to be in Qt 5.0, but do need to be structured so we can cleanly add new features in 5.1, 5.2
• Much depends on success of OpenGov
• All contributions from KDE must be seen as for better of Qt not just KDE, we need to be pragmatic
• If get in early with quality contributions can establish position of trust and authority
• Start small with some test cases to prove process, gain trust:
  • KUrl/QUrl - Very simple case with minimal change required
  • KLineEdit/QLineEdit(?) - More involved case
  • QDateTime - Test for working with Qt Brisbane to develop common requirements
  • Printing - Big test case for major changes + maintainership
• Review progress at Desktop Summit, if good progress then commit to full process
• Need class-by-class review:
  • Work with dependencies team, need common notes somewhere
  • Will need expert advice on each class, we can't know every reason for duplication
  • Find if a Qt equivalent (not always obvious!)
  • Determine why KDE version exists
  • Determine if Qt version is already good enough (may have improved since K class created)
  • Determine if we really still need any extra features
  • Need to consider features, quality, performance
  • Reach a conclusion:
    • Keep K class entirely
    • Keep K class but move some features to Qt
    • Remove K class, use Q class completely
    • Remove K class, use Q class with new K helper class
• Licence:
  • Need review by eV lawyers to reassure contributors they don't lose rights, are fully informed of consequences, start asap as may take time
  • Create list of known contributors who have/will agree to Qt license so we can reuse their code if appropriate (will still need explicit agreement per contribution?)
  • Need to be very careful don't copy code of those who oppose code donations
• Automated tools for convert?

Specific classes/modules

Some obvious stuff from off top of our collective head:

• QtLocation: Move QGeoCoordinate and poss QGeoAddress from QtLocation to QtCore as fundamental data type
• KUrl / QUrl
• KIcon / QIcon
• KDateTime / QDateTime
• KLocale / QLocale
• KAction / QAction
• KSSL*
• KCodec
• KlineEdit / QlineEdit
• KComboBox / QComboBox
• KCompleter
• ...

Some random other notes:

• QDate/QTime don't have a qHash?