KDAB contributions to Qt 5.1
07.08.2013
The release of Qt 5.0 brought to an end the first opportunity in 7 years to break source and binary compatibility for a Qt release. It was a huge effort from across all disciplines and contributions, from design discussions, documentation and development to infrastructure, administration, marketing, testing and packaging.
KDAB made significant contributions to the Qt 5.0 release, and Qt 5.1 is no different. KDAB contributions covered the range of code and documentation patches and release and package testing,
OpenGL updates
Sean already posted a series of posts about the changes in Qt 5.1 OpenGL APIs contributed by KDAB. The newest OpenGL features and extensions from the OpenGL 4.3 specifications published by Khronos are being made available through Qt APIs, turning runtime errors into compile-time errors. The posts demonstrate the growing number of powerful features and continued ease of use for anyone making full use of their GPU features. Among the significant contributions is the QOpenGLDebug API which was described in the fourth post in the series.
CMake simplicity and flexibility
There has been ongoing work on the CMake files distributed with Qt 5.
Most significant among the changes is a patch to utilize new target usage requirements features in CMake 2.8.11. As shown in the documentation, this allows consumers of Qt 5.1 to avoid the need to specify include directories, compile definitions, the position independent code flag, or the winmain link library on Windows. As it is a built-in CMake feature, this also works with Qt 4 code using CMake.
New features in CMake 2.8.9 made it possible to create an ‘umbrella’ Qt5 package for use with cmake. That means that rather than finding each module with multiple lines
find_package(Qt5Widgets)
find_package(Qt5Xml)
find_package(Qt5Sql)
find_package(Qt5Script)As of Qt 5.1, it is now possible to specify the modules as components of the Qt5 package.
find_package(Qt5 COMPONENTS Widgets Xml Sql Script)Module-specific diagnostics are reported if one of the components can not be found.
Also noteworthy for some projects is the ability to separate build Qt 4 and Qt 5 dependent binaries in one buildsystem. This is a benefit when porting large, multi-executable codebases and advanced features like AUTOMOC are also non-conflicting. CMake also now issues error diagnostics when a binary is linked to both Qt 4 and Qt 5 targets at the same time.
An important bugfix was also added to this release for several Linux distributions. Fedora and others are now symlinking /lib to /usr/lib, which breaks relative path calculations relying on relative positions of the bin/ directory etc. The solution in the newest CMake release and in Qt 5.1 are the same and special-cases the specific problematic scenario.
Many other changes went into the CMake files such as new unit tests and patches resulting from various feedback recieved when packaging Qt 5.0.
New modules in Qt 5.1
Qt 5.1 introduced several new modules including QtX11Extras and QtSensors, where KDAB made many contributions. The QtX11Extras module is a replacement for the QX11Info header from Qt 4. As Qt 5 minimizes platform-dependent and visualization-dependent code in the core, this had to be moved to a separate module. In QtSensors, KDAB implemented the necessary API to make sensors in Blackberry devices work with Qt 5.
Incremental updates
QTreeView gained the ability to use the new Qt::ItemNeverHasChildren flag for items in the tree. This is a marker that a QAbstractItemModel implementation can use to gain some performance improvements. Some visual bugs were also fixed on Mac for scroll bars and systray items.
As part of the feature merger between QPointer and QWeakPointer for the purpose of QObject tracking, a bug fix needed to be added to handle the case of const template arguments.
Another improvement to automated registration of meta-types, which was started for Qt 5.0, was also extended in Qt 5.1 to include method parameters used with QSignalSpy.
very good !