Last week in Qt development (week 19, 2012)

17.05.2012 steveire 2 comments

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 more of the QPA API changes and conventions, discussion of implementation of icon themes, packaging concerns, and exception handling. The number of interesting feature commits is still declining, which reflects the focus on bug fixing and stability towards Qt 5.0.

QPA API naming convention changed

The proposal to set a different naming convention for the Qt Platform Abstraction API, as previously discussed has landed in Qt. As the set of QPlatform* classes do not guarantee Binary compatibility, they should not be used in user applications, but only in platform plugins.

The platform abstraction API is in headers which are grouped in a qpa directory, so that it is necessary to use

  #include <qpa/qplatformscreen.h>

for example. The user also needs to use QT += -private in qmake code to use the QPA APIs.

QScreen gets refreshRate API

The QScreen class represents a screen in Qt 5. Recently its API was extended to notify about the refresh rate of a screen on particular platforms.

QScreen is part of the application developer facing QPA API. It provides read-only access to properties, and notifies the application developer when those change. The corresponding platform developer API is QPlatformScreen, which has the binary compatibility guarantees set out above (or lack thereof). QPlatformScreen has a virtual refreshRate method in this case which platform developers can reimplement to differ from the default 60 fps.

Homogenising Shared value class copying and moving

A proposal from KDAB engineeer Marc Mutz to make copying and moving of some pimpl’d classes more consistent was submitted. This proposal adds swap() member methods to many classes to the copy-swap idiom easy and effective. Copy constructors can then be implemented in terms of a swap method, which in the case of pimpl’d classes means just swapping a pointer, so it is very fast and does not fail.

This could have performance benefits in Qt, but does not affect 3rd party code.

Icon theme implementation

An interesting thread brought up the issue of icon themes and in particular conformance to a FreeDesktop specification for naming conventions.

Qt 4 had some built-in handling for icon sets in KDE and GNOME environmentsl, but new QPA APIs in Qt 5 will allow giving more control to the platform plugin regarding how icons are loaded from a theme.

Optimizing Qt development on Ubuntu

A report from the Ubuntu Developer Summit brought up some feedback from packagers regarding Qt development. The issues regard seamless integration of the Qt SDK, avoiding conflicts between Qt 4 and Qt 5, and how the appropriate platform plugin should be loaded.

QtDeclarative compatibility module removed

Anyone building the QtDeclarative module may have seen very long command lines with preprocessor defines between QtDeclarative class names and QtQuick class names. This was a temporary measure to raise the available source compatibility of other Qt modules depending on Qt declarative, but QtDeclarative was not a real module.

The module name situation has now settled down regarding declarative. The Qt 4 module ‘QtDeclarative’ is named ‘QtQuick1’ in Qt 5, and should not be used for new code. In Qt 5, the qtdeclarative repository contains two new libraries – QtQml and QtQuick. These two libraries were split from the Qt 4 QtDeclarative code, so they have the same API, but different class names. It seems like a confusing naming situation for people undergoing the transition, but the take-away is that in porting from Qt 4 to Qt 5 you should port from QtDeclarative to QtQml and QtQuick modules.

Exceptions in Qt 5

The use and configuration of exceptions has been cleaned up somewhat in Qt 5. On some platforms, notably WinCE, they have been disabled at configuration time, which causes problems for QtXmlPatterns which itself uses exceptions. Several other Qt modules use exceptions such as QtConcurrent, and the rest should be as immune to exceptions in 3rd party code as possible. Qt does not generally provide strong exception safety guarantees, and does not handle them properly.

The solution is to disable exceptions wherever they are not explicitly needed and enable them only in modules where they are required.

Preparations towards Qt Contributor Summit 2012

The planning around the upcoming Qt Contributor Summit in Berlin is ongoing. The summit is designed to be an unconference, allowing attendees to engage in many ad-hoc discussions, but a partial program has also been added to give some structure to the event, and to ensure that some topics get covered.