Last week in Qt development (week 29 2012)
25.07.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 some features made possible in QML, greater possibilities for platform configuration integration, discussion about the use of color profiles in Qt, and various efforts towards release-readiness.
New QML 2 showcase
A new showcase of QML 2 applications from the Qt team were publicized last week. The applications are already available in the qtdeclarative repository as example applications. The applications and video show the changing and new possibilities made possible for QML 2.
Native API for event filtering
KDAB engineer David Faure added API for native event handling to Qt. The rationale behind the new API is well explained in the commit message. It is intended to be a platform-specific equivalent to the familiar QObject::installEventFilter API.
Performance improvement in library and plugin loading
KDAB engineer Sean Harmer implemented some optimizations for the algorithm Qt uses to find and load libraries and plugins.
More platform specific APIs for behavior configuration
Recent work makes it possible to use platform configurations for variables which have previously only been part of the style, such as the double-click interval, start-drag-distance etc.
This paves the way for greater platform integration with the underlying platform configuration management APIs.
Waiting for Windows in QtTest
New API in the QtTest module has been added for waiting for particular windows to be exposed or made active. The new API is more precise and reliable than the equivalent API in Qt 4.
Color Profile support in Qt
There was a discussion about color profile APIs in Qt, as it could appear in future Qt 5 API. This is a complex issue, and something that Qt so far has never supported, and there are existing software offerings which could be integrated with.
Fixes for WinCE Qt 5 port
KDAB has been contributing more fixes for the port of Qt 5 to WinCE. The changes last week involve mostly concerns around window state and behavior, and are very WinCE specific.
Many documentation cleanups
As usual last week, there was a continued push to clean up the documentation errors currently present in Qt 5 repositories. Much of this effort last week has been focused on removal of references to Qt3Support API which is no longer available in Qt 5.
High quality documentation is one of the requirements of a Qt release, so this work is very welcome.
Buildsystem source compatibilty with QtDeclarative from Qt 4
The qmake buildsystem may get additional backwards compatibility for users of QML1 in Qt 4. In Qt 4, users of QML added QT += declarative to qmake, but the way to do the same in Qt 5 is to use QT += quick1.
Currently QT += declarative is an error in Qt 5, but that could be changed to be only a deprecated way to use it in its renamed form, QtQuick1, in Qt 5.
Users of CMake can already use extra-cmake-modules for backwards compatibility.
Replacing Q_WS_* preprocessor defines with runtime checks
The task of removing all Q_WS_* style defines from Qt 5 is on-going, and being worked on. A recent patch is typical of what is required in that process.
While a lot of work is being done in this area, there are still more than 700 uses of such preprocessor defines. These are all dead code in Qt 5, so all help with replacing them with OS checks or runtime checks is appreciated.
Some of the code surrounded by define checks like that is unit test code, which means that relevant parts of Qt have unit tests which are effectively commented out.
Use of internal headers in public QtTest headers removed
The header issue I wrote about previously has been resolved. Users of QtTest are no longer required to use private headers of QtGui.
Hi, I’m very curious and excited about if Qt 5 will support Windows RT and ot course let us to make Metro style applications. Anyone has any information(new ones) please submit here and let us know the progress.
We were not able to build Qt Quick because of the lack of a port of ANGLE meant that there was no OpenGL support. Some “shortcuts” were needed to get Qt 5 to build, such as taking some libraries and header files from the Windows 7 SDK. These may have an impact on whether Qt could meet the Microsoft Store guidelines (See the “Risks and Unknowns” section).