< KDE Core | Platform 11 Warning This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible. Contents 1 Team Members 2 Post-it Notes 3 Notes 4 Specific classes/modules 5 Locale 6 Date/Time 7 Printing 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? Locale http://community.kde.org/KDE_Core/KLocale http://community.kde.org/KDE_Core/ISO_Codes What's wrong with KLocale: Gtk/Qt apps running under kde-workspace don't use KDE locale KDE apps running under other platforms/workspaces do not use host locale Class merges settings, formatters, parsers and translations in one giant blob Unnecessary dependency for Qt-Addon libraries What's great about KLocale: Users can change settings Apps can change settings Superior settings, date/time, etc support What's wrong with QLocale: Not all settings are supported Apps and users unable to change settings What's good with QLocale: Uses host settings on all platforms Low-level common class so good for Qt Addons The Plan: Add all KDE settings that already exist in CLDR to QLocale Use QLocale to replace KLocale's role as settings container Gives correct Windows, Mac, Gnome, Meego settings KDE Workspace to set locale envvar on login if KDE locale different to system locale Gives correct locale Gtk/Qt apps KCM to load settings from QLocale, write out as both POSIX and CLDR format files only if user chooses different settings locale envvar then set to absolute path to users POSIX file so all Gtk apps get right settings QLocale loads CLDR file so KDE/Qt apps get right settings Apps use parser/formatter classes/api's to alter settings for one-off calls rather than changing the locale itself, or create a whole new locale object. Big Questions: Date/Time formats: Keep POSIX formats (need own formatter/parser that translates Unicode format) or switch to Unicode format (not SC, QDateTime may not support all our features) How will QLocale load custom CLDR? Fallback to custom POSIX but lacks some features. Date/Time http://community.kde.org/KDE_Core/QtMerge/QDateTime Printing https://qt.gitorious.org/~odysseus/qt/odysseus-clone/commits/qprinter-page-handling https://qt.gitorious.org/~odysseus/qt/odysseus-clone/commits/windows-page-set Retrieved from "https://community.kde.org/index.php?title=KDE_Core/Platform_11/Eliminating_Duplication_With_Qt&oldid=12969" This page was last edited on 6 June 2011, at 16:31. Content is available under Creative Commons License SA 4.0 unless otherwise noted.