Last week in Qt development (week 17 2012)

25.04.2012 steveire 2 comments

Introduction

This is the first of many posts about Qt 5 development to appear on the KDAB blog.

The intent of these posts is to be a summary of development in the qtbase repository and discussions on the Qt Project mailing lists. The reporting is not limited to KDAB contributions to Qt, but aims to be a collection of relevant developments in as neutral a way as possible.

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.

Towards release readiness

Early last week the api_changes branch was merged into the master branch. The api_changes branch was for more significant changes to Qt which were still required while the alpha was still being developed in the master branch. Some commits are still going into the api_changes branch, but most effort is returned to creating release-readiness in the master branch.

Part of that effort is fixing any remaining compiler warnings and removing some ‘insignificant’ markers from unit tests. Tests marked as ‘insignificant’ can fail without blocking the integration of patches. Usually, this has been useful so that tests that fail non-deterministically or for unknown reasons on certain platforms while the source of the non-determinism is found. Processing these issues will bring us closer to a Qt 5 beta release.

Qt 5 on QNX efforts

Work continues at pace to ensure that Qt5 will provide an exceptional experience for both the developers and end-users of Qt on BlackBerry and QNX with tight integration to platform services and tooling, including the Qt Creator IDE.

FreeBSD patches for Qt 5

Also in the area of ‘Unix-but-not-Linux-or-OSX’, patches is some patches to modernize the FreeBSD build system details for Qt 5. The compiler requirement has been updated to GCC 4.6, which is consistent with the compiler requirement on other platforms using GCC.

Presumably getting Solaris and other Unix ready for Qt 5 will require a similar effort, but it is not known if anyone in the community is currently undertaking that effort.

Unit tests for the CMake buildsystem files

KDAB contributed CMake configuration files for Qt 5 several months ago together with tests that must be run manually.

While the tests are useful, changes in behavior have at times caused tests to fail accidentally because they must be run manually.

Efforts last week went into making the cmake based unit tests run with the rest of the Qt 5 test suite. This will make it possible to run them as part of Continuous Integration and make regressions far less likely.

Documentation modularization

One of the bigger changes to happen in Qt 5 and towards the end of Qt 4 has been modularization. This effort is intended to reduce the dependencies between different parts of Qt on all levels – on the library binaries level, the build system, the release cycles and maintenance, source code repositories, and of course documentation.

Modular documentation means that it will be quicker and easier for developers to build the documentation for the modules they are interested in, but also has some consequences for the links between modules. As dependency is always one way, and for example, the QtWidgets module depends on the QtCore module, it will not be possible for QObject to document that it is inherited by QWidget, as it currently does. This, of course, makes sense in a modularized world anyway because the modules that depend on QtCore (or even a particular version of QtCore) are not ‘stable’, they change over time, so the documentation would be out of date.

The readiness of the Qt 5.0 Beta will also depend on some level on the progress of documentation quality and modularization.

The place of QML in Qt applications

Alan Alpert wrote an article about the role of QML in Qt based applications.

This forms part of a larger discussion on the same subject with a context of support for and relevance of widget based applications in Qt 5.

The focus of the article is generally Qt 5 and QML 2, but much of it applies equally to Qt 4 based QML/C++ hybrid applications: “The logic of how to manipulate your application’s data, if it is not exposed to the end-user, should not be exposed to QML.”, and “[QML being the user-facing layer] means that the visual representation of the application is done with QML. It also means that logic reacting to user input is done in QML.”

QHash randomization arrives in Qt 5

Late in 2011 a security issue was revealed which affected most implementations of hash tables used popularly today. The most effective defense against attacks exploiting the security issue is randomization of the hash value of keys at runtime.

As Qt is also affected by the issue there was also an effort to implement the same defense in Qt, which was completed last week. The completion of the task took a long time because elements in a QHash are ordered consistently, though not in a documented way. Over the years, code has been implemented with assumptions about the consistent ordering, even accidentally. Many other supplemental patches were necessary to remove those assumptions, and now the change has finally landed. (Giuseppe D’Angelo is a recent hire of KDAB, but was not sponsored by KDAB to complete this work).

This will affect code of all users of Qt which have written code which relies in a non-obvious way on the ordering of elements in a QHash, and on code which forward-declares a qHash function for any type.

Clarifying guarantees about QPA

There was a discussion regarding the ‘self-documenting’ nature of parts of Qt as being internal.

Until now, header files ending in _p.h were considered ‘private API’, and contain a clear warning to that effect. That means that those files do not carry any guarantees of source compatibility (whether it is intended for you to rewrite parts of your code with a new release) or binary compatibility (whether you need to rebuild your software with each new Qt release.

Another way of ‘self-documenting’ for methods and classes without guarantees is not documenting them.

These practices have worked up to now, but with the QPA system, the platform abstraction for Qt, they do not match up anymore. The problem is that QPA is not yet intended to be ‘stable’ API with the same guarantees as the rest of Qt, but also must be documented so that developers porting Qt to their platform know how to use it. The proposed solution is an extension of the self-documentation based on having platform in method names for example.

The message is that the platform abstraction APIs are not intended to be used by applications (which can use other, stable APIs).