First look: Qt 5 makes JavaScript a first-class citizen for app development

The community behind the Qt project has issued an alpha release of Qt 5.

Qt Quick on the desktop

QML was originally created for building touchscreen mobile interfaces and still has a strong emphasis on that usage scenario. The key to making Qt Quick equally compelling for desktop user interface development is the Qt Quick Components project, which provides custom QML widget sets.

The Qt Quick Components desktop set is designed to use the native widget theme of the underlying operating system. It accomplishes this via QStyle, which relies on each platform's own individual themed drawing APIs. In the long run, Qt Quick could eventually provide opportunities for much better native platform integration than QWidget. With Qt Quick, developers will have the option of using separate QML layouts on each platform that use platforms-specific design idioms.

Because of the way that application logic and user interface layout are decoupled in properly-developed Qt Quick applications, it's not too much trouble to take that approach. The Qt Quick Components desktop elements aren't quite mature yet and adding support for the platform-specific idioms is still a work in progress. Despite the minor weaknesses, some of the things you can already do by mixing Qt Quick Components and custom QML elements in Qt 4.x are really impressive.

A Qt Quick Components desktop demo published by Nokia

Qt Quick aside, it's worth noting there are still a lot of unanswered questions about cross-platform desktop support in Qt 5. I haven't seen any practical discussions yet about how to support Metro integration on Windows. On Mac OS X, Qt is missing support for Lion's fullscreen mode, new scrollbar behavior, and other similar features. Several additional issues that prevented Qt applications from being accepted in Apple's Mac App Store were recently resolved in Qt 4.8.1.

Ensuring that Qt applications look and feel as native as possible on each of the major platforms has historically been a major focus of the toolkit. That goal seems to be a lower priority now. Issues like the poor Lion support may be attributed to a lack of interest among the Qt maintainers in solving those kinds of problems.

Limitations

Although Qt Quick has a lot to offer developers, there are still some critical technical limitations in the framework that currently prevent it from being a fully-featured replacement for the conventional QWidget stack. One major problem is that the underlying classes behind the standard QML elements are in private headers and can't easily be subclassed in C++.

There are also a lot of basic Qt features that simply aren't accessible if you are using Qt Quick. For example, the toolkit's powerful text layout and formatting framework, called Scribe, is heavily crippled in QML applications. There doesn't appear to be a way to access a QTextDocument or QTextCursor from the QML TextEdit element.

Although the TextEdit element is still using those classes under the hood, they aren't accessible. Instead, you get simple JavaScript wrapper methods that are a lot less functional and powerful. There are similar issues across the board in the various QML elements.

Another example of a feature gap in QML is the lack of good support for handling tree interfaces. If you have a hierarchical QAbstractListModel that is bound to a QTreeView in your QWidget-based application, it's going to be a major pain to port that interface to Qt Quick. Flat list models map beautifully to the QML ListView element, but nested models don't.

Transitions

The transition from QWidget to QML will obviously not happen overnight. The QWidget stack will be available for a long time. It's going to be consolidated into a separate library that developers can choose to use with their applications. Although the QWidget classes won't be deprecated, they are not going to be the focus of development going forward.

The standing policy among the Qt maintainers is that QWidget is "finished" and won't see significant further improvement unless independent community members want to step up and take on that role for the module. QtScript, which is arguably made redundant by the inherent scripting capabilities offered through QML, is going to be in a similar position.

The major changes to Qt Quick introduced in Qt 5 have the potential to raise some compatibility issues. The QML syntax isn't going to face major syntactic changes, but the architectural overhaul under the hood is significant enough that it could potentially lead to subtle changes in behavior. For compatibility purposes, developers will have the option of continuing to use the legacy Qt 4.x version of Qt Quick in Qt 5. This will be provided by a separate module called Qt Quick 1.

A BitTorrent client I made with C++ and Qt Quick

Getting an existing Qt 4.x application to compile with Qt 5 is reportedly not too much trouble. The developers have already updated Qt Creator, the official Qt integrated development environment, so that it compiles under Qt 5. Of course, it's still using QWidgets for most of its user interface. It's going to take longer to bring large applications like Qt Creator into full alignment with the Qt 5 vision.

C++11 support and other features

This article focused primarily on Qt Quick and the new Qt application development model, but there are also a lot of other noteworthy changes in Qt 5. The Qt Platform Abstraction (QPA) system, which emerged from the Lighthouse project, will be used for all of the Qt ports in version 5.

The phrase "Qt Everywhere" has historically been a major part of Qt branding. QPA carries that motto forward by improving the toolkit's portability. QPA lowers the barrier to bringing up Qt on new embedded systems. It also makes it easier for third-party developers in the Qt community to adapt the toolkit for use on other platforms. There are experimental third-party ports with varying levels of maturity for Haiku, Android, iOS, and other platforms. Making QPA the basis for all officially-supported ports is going to improve consistency and simplify managing the platform-specific parts.

KDE applications running on Haiku via the Qt port

For application developers, there are several useful new libraries that have been added to the Qt stack. These include an official JSON library in QtCore and a Mime type database library for determining the type of a file. Several old libraries that are no longer needed are being dropped, including QHttp. That was effectively replaced by the vastly superior QNetworkAccessManager quite some time ago.

Another area where application developers can expect to see significant improvement is C++11 support. I'm personally very enthusiastic about the new SLOT syntax that adds support for C++11 lambda expressions. This will allow developers to implement a signal handler with an inline anonymous function instead of having to bind the slot to a separate method. Another nice improvement made possible through C++11 is support for compile-time type checking on signal and slot connections. Of course, not all compilers actually support C++11 yet, so these features will only be available when using a recent version of GCC or other suitably modern compiler.

Conclusion

It's important to remember that Qt 5 is still a work in progress. There are many things that will likely be improved before the official release. There is also a lot of work that will be done in subsequent point updates to fully deliver on the promise of the next-generation Qt development model.

Although the transition is going to be painful for quite a few application developers, it's well worth the reward. The current trajectory and long-term roadmap are excellent. The changes that Qt 5 will bring are going to make the toolkit even more modern and competitive. Qt Quick is well-suited for rapid development. It has the potential to become an ideal solution for building cross-platform software when the Qt Quick Components project matures and other problems are resolved.

I've long since given up on trying to make sense of Nokia's incoherent mobile platform strategy, but it's clear the company is still committed to making major technical investments in Qt. The transition to a more open governance and development model has further cemented the toolkit's long-term sustainability. There is a lot of really healthy community engagement around Qt and there are more companies participating in Qt development.

Because Qt 5 is in the alpha release stage, binary builds are not currently available. If you want to test it yourself, you will have to download and compile the source code. For additional details about the Qt 5 alpha, you can refer to the official release announcement.