KDE Core/Platform 11/Eliminating Duplication With Qt: Difference between revisions
< KDE Core | Platform 11
Line 73: | Line 73: | ||
* QDate/QTime don't have a qHash? | * QDate/QTime don't have a qHash? | ||
== Locale == | == Locale == |
Revision as of 21:06, 5 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
- 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
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.