Last week in Qt development

30.04.2012 steveire 4 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.

Default codec for QStrings to change to UTF-8

Discussions and investigations into using UTF-8 as the default codec for QStrings have been going on for some time. A thread on the development mailing list about an apparent regression in required encoding for source files kick-started the discussion, and a patch was created to implement the change.

The end result is that in Qt 5 it will be possible to use the QString constructor and other methods that take a const char * with UTF-8 data. Whereas in Qt 4 one had to write:

    QString str = QString::fromUtf8("Hello世界World!你好！");

In Qt 5 this will just be

    QString str = QString("Hello世界World!你好！");

The second form compiled in Qt 4 times too, but would have resulted in some form of Mojibake in UIs.

Mock objects for Qt

There is some interest in a framework in Qt for mock objects. Mock objects are a tool for enhancement of unit testing. They can be used to test classes that have dependencies which are more complex, slow, or impractical for use in unit tests.

The existing approach in an experimental repository has interesting unit tests showing how the ideas could be applied to Qt.

Qt 4.8.2 release candidate tagged

Qt 4 is still receiving bug fixes and improvements while the development of Qt 5 is ongoing. A new release should arrive in the coming days.

The passing of passing by reference?

The way that arguments should be passed to methods is a complex topic depending on the structure and size of the object being passed, and the signature of the method being used.

Last week there was a discussion about how new features in C++11 can affect the choice of how arguments should be represented in methods. In Qt 4, most methods that take a const QString & for example do so to avoid copying the QString (and avoiding atomic operations on its refcount), as would happen if it took a QString by value.

With the arrival of C++11 and ‘move semantics’ the compiler can be more efficient (with the correct syntax) at creating CPU instructions which move objects, rather than copying them. This is mostly appropriate for temporary objects where the type has a ‘C++11 move constructor’ (most Qt value classes have them now).

The API of all existing classes in Qt 5 will not be changed to take advantage of this language feature, but new APIs added to Qt 5 in the future may do. The topic needs some more research before being accepted.

QML File dialog component

With the move towards QML for making complex UIs, the need for complex components also presents itself. There is a QtComponents effort to create such QML elements, but one of the missing pieces is a file chooser dialog. There is some movement on API and functionality requirements for such a dialog, but it is indeed a difficult problem.

Towards QLocale backed by ICU

Qt 5 will be migrating to using ICU for providing locale data. One of the patches towards this goal was a refactoring of the QLocale implementation. In Qt 5.1 we should see more progress towards using ICU. This should make it possible to expose more features of ICU through the Qt APIs in future releases.

A mkspec for building Qt 5 with iOS

A set of files used for building Qt with iOS as well as for device simulators has landed in the repository.

While this works towards the possibility of creating iOS applications with Qt 5, the distribution model for that platform poses separate problems.

QRegExp API-constness change

QRegExp in Qt 4 has several methods which are marked as const, but which actually modify the object being operated on. In Qt 5 the methods indexIn, lastIndexIn and exactMatch have been changed to be non-const. This is a source incompatible change.

Porting will be required whenever calling one of those methods on a const QRegExp, for example, one passed into a method as const QRegExp &, a static const QRegExp (which is one of the problematic constructs this change aims to avoid), and calling a member QRegExp of a class in a const method.

Usually porting involves creating a copy of the QRegExp object.

QObject connection API without string comparison

One of the big features newly available in Qt 5 is the possibility of making new style signal/slot connections with function pointers directly instead of indirectly using function signatures in a string. Apart from providing type safety for the arguments in the connection, this method is faster becuase string comparison is no longer needed during the connection.

There are other APIs in Qt though where string comparison appears in the context of signal slot connections: the connectNotify and disconnectNotify methods. A patch is in progress which changes those virtual methods from containing a const char *. Another patch makes it possible to use function pointers in the implementation of such methods.