KDE Core/Platform 11/Eliminating Duplication With Qt: Difference between revisions

From KDE Community Wiki
Line 21: Line 21:


* A Good Thing (TM), let's do it
* 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
* 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
* 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
* Freeze kdelibs4, but not too hard may need changes or can backport some KDE5 stuff
* 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
* Much depends on success of OpenGov
* 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
* All contributions from KDE must be seen as for better of Qt not just KDE, we need to be pragmatic
Line 50: Line 46:
*** Remove K class, use Q class completely
*** Remove K class, use Q class completely
*** Remove K class, use Q class with new K helper class
*** 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


== Specific classes/modules ==
== Specific classes/modules ==

Revision as of 10:04, 3 June 2011

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

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?