Last week in Qt development (week 23 2012)
20.06.2012
This post is part of an ongoing series about developments and discussions in Qt.
Some parts of this report are still under discussion, and don’t necessarily reflect the final state of Qt 5. The target audience is people involved in Qt development itself, but without the time to follow everything that happens, and others with a strong interest in Qt, Qt 5, and the community.
This week we cover the use of C++11 by default in Qt where available, deprecation of the QWeakPointer feature of tracking QObjects, updates to the Qt plugin system, and quality requirements for primary Qt platforms.
C++11 by default
Qt now detects C++11 capability of the compiler when being configured, and enables C++11 features if possible. The detection of compiler capability currently works only for clang, g++ and Intel compilers.
C++11 provides many advantages over C++98, and for Qt 5 is the preferred and most optimal configuration. A recent commit to Qt 5 makes use of C++11 to increase source compatibility while porting.
QPointer favored over QWeakPointer
In Qt 4.6, QWeakPointer gained the ability to track QObjects. This was a feature already possible with the QPointer class, but with a faster implementation.
In Qt 5, the opportunity of breaking binary compatibility was taken to implement QPointer in terms of QWeakPointer, so that it is as efficient as QWeakPointer. Although QPointer was deprecated initially in Qt 5, it was undeprecated given that QWeakPointer is not a vastly superior solution anymore.
There still remained two problems, which were that now Qt had two ways of tracking QObjects instead of just one, and that a QWeakPointer which is used to track a QObject can be converted to a QSharedPointer (because the API allows it) with undefined behaviour. Finally, recently both of those problems were solved by deprecating the use of QWeakPointer to track QObjects.
This creates an interesting porting story, but that does not have too much impact anyway.
Plugin changes and documentation
The porting burden of creating plugins was completed and documented. The FILE component is optional, so for plugins which do not need to add any readable metadata to the binaries, it can be omitted, rather than creating emtpy JSON objects. Many other commits in the week related to porting existing plugins in Qt to the new system.
Making tests build without QtWidgets
Due to modularization, it is easier to use parts of Qt without using the QtWidgets module – either if QML is preferred, or if there is no need for a gui at all. Recent work on the unit tests in Qt ensure that most of the relevant unit tests can be executed if the QtWidgets module is not used.
Unicode and Locale updates
The Unicode code tables used in Qt have been updated to version 6.1. This is part of a much larger amount of work by Konstantin Ritt as part of Open Governance. Other work includes updates and fixes for line breaking algorithms, and platform specific codepaths.
For Locale code, Qt is making increasing use of ICU. This is one of the longest running Qt 5 features in planning and development so far, and will provide ongoing new features to the Qt locale system.
Planning the Qt 5 launch
The Marketing engine around Qt 5 is gathering information and features in preparation for the first release.
Becoming a Tier 1 Qt platform
Qt platform support is extensive, but tiered. Tier 1 platforms are those which are expected to participate in all of the testing and continuous integration as is done on other primary Qt platforms, as was discussed at the Qt Contributors Summit last year. A release blocking bug on a Tier 1 platform is considered a release blocking bug for Qt as a whole. A thread recently highlighted the criteria currently considered requirements to be a Tier 1 Qt platform.