Last week in Qt development (week 26 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 documentation for the new plugin system, Qt Contributor Summit reports, buildsystem improvements and standards-conformant Cookie handling.

New Plugin system documentation

The plugin loading system has changed entirely in Qt 5, as I wrote previously in porting notes. The new system is now documented more completely by removing references to the old API which no longer works (Q_EXPORT_PLUGIN2 etc).

Double buffering removed from sockets

When working with QIODevice, one of the features available is built-in buffering. QAbstractSocket also has built-in buffering, which the Qt socket classes take advantage of. However, this means that for QLocalSocket for example, all data is buffered twice. This is resolved in Qt 5 by removing the buffering in QAbstractSocket. As all implementations of that class also already implement QIODevice, there is already sufficient buffering.

QPA implementation for window masks

With the refactoring of all platform specific code in Qt into plugins and abstractions, some features are still being worked on in the Qt 5 abstractions. One of those such features is the window masks feature. The necessary platform specific API has been added to QPA for implementing this feature, but there is no abstracted API for it yet.

Updating the Cookie handling implementation

Recently (just over 1 year ago) a RFC was published detailing how HTTP Cookies should be handled by HTTP clients. Of course, as Qt provides APIs for that in the form of QNetworkCookie, it should also be compliant to the RFC. Recent patches to Qt work towards compliance with the HTTP-Cookies test suite published by the IETF.

Application Display Name in QGuiApplication

QGuiApplication now has an API for setting the display name of the application. This is different from the name of the application in that it appears in the titles of windows in the application, and should be translated.

Static build related macros simplified

The preprocessor definitions and qmake configuration used to build with static Qt libraries has been simplified. Although the build for static Qt 5 libraries is updated, running executables with such a build configuration is not yet working.

qmake buildsystem modernized

Through two feature branches which were merged in recent weeks, the implementation of qmake and the buildsystem for Qt were updated dramatically. This has included the introduction of new features, removal or deprecation of old features and cleanup of the code.

QStandardItemModel moved to QtGui

Earlier in the Qt 5 development cycle, some of the implementations of QAbstractItemModel in Qt were moved from the QtWidgets module to QtCore. QStandardItemModel was not moved at the time because it depends on QIcon, which was in the QtWidgets module. As QIcon was returned to QtGui some time ago, it became possible to move QStandardItemModel to QtGui also. This makes it easier to use the class in non-Widgets QML applications.

Better QObject conversions for QMetaType

QMetaType now stores the QMetaObject associated with a QObject subclass. This means that if a QVariant contains a pointer to a subclass of QObject (Such as a QAbstractItemModel*), QVariant::canConvert(QMetaType::QObjectStar) and QVariant::convert(QMetaType::QObjectStar) will return true. This can make it easier to create QtDeclarative applications,but the patch to enable that is still in review.