Thoughts about Qt 5

Qt 4.0 was released in June 2005, almost six years ago. A lot has changed in the software industry over these years. While application development back then happened mostly on desktop systems, mobile devices connected to the web have become increasingly popular. User interface technology has moved from static widgets to a fluid touch based experience. Since Qt 4.0 we have released seven minor versions of Qt to stay ahead of development needs, for example by releasing Qt Quick. Within the growing Qt user base, we have had a strong up-take and new needs from embedded and mobile app and UI developers.

To also, in the future, be a leading edge development framework across multiple industries, Qt needs to continue to renew itself. Qt 4 has been an evolution, and I have been thinking about what future Qt versions might look like from a technical perspective. Over the last years we have been working on laying the foundations for the next major release. I see Qt Quick, QML Scenegraph and Project Lighthouse– combined with an increased focus on Qt Webkit - as the foundation which we plan to use to move towards a new major release of Qt.

Given that Qt is moving into open governance mode in the upcoming months, I wanted to share my thinking with the Qt community in order to kick off the discussions about what I see as the technical architecture for Qt 5.

Objectives with next major version of Qt (Qt 5)

• Make better use of the GPU, allowing you to create smooth (and accelerated) graphics performance even with limited resources;
• Making your creation of advanced applications and UIs easier and faster (with QML and Javascript);
• Make apps connected to the web be as powerful as possible, i.e. to embed and power up web content and services into any Qt app; and
• Reduce the complexity and amount of code required to maintain and implement a port.

Qt 4.7 contains some legacy code that prevents us from making Qt as good as possible for creating next generation applications and UIs. While most parts are still very relevant to our developer base, some parts are also blocking our way in the 4.x frame.

Making it straightforward to move applications from Qt 4 to Qt 5

With Qt 5 we plan to make selected changes in the APIs and leave behind limitations from the past where required for the best of the future. For those of you that were with us for the transition of Qt 3 to Qt 4, we do not plan to repeat that difficult transition with Qt 5. To be explicit here – we believe we can keep source compatibility for the majority of cases, but we believe that breaking binary compatibility is needed. We will do everything to avoid breaking any fundamentals and to make it easy and very straightforward for the wide majority of applications to move from Qt 4 to Qt 5.

The initial thinking is that Qt 5 will focus on a small set of operating systems/platforms (i.e. platforms Wayland and X11 on Linux, Mac and Windows). The total number of platforms will depend on the community efforts invested as Qt moves into open governance mode. Other operating systems currently supported by Qt 4 (esp. commercial UNIX systems) will not be in focus for Nokia. The goal of the Qt 5 project is to offer the best possible functionality on each platform, implying that Qt will begin to offer more differentiated functionality on some OS’s, while still offering efficient re-use for the absolute majority of the code across platforms.

Developed in the open, together with you, with strong backing from Nokia

Another major change with Qt 5 will be in the development model. Qt 4 was mainly developed in-house in Trolltech and Nokia and the results were published to the developer community. Qt 5 we plan to develop in the open, as an open source project from the very start. There will not be any differences between developers working on Qt from inside Nokia or contributors from the outside.

If you want to involve yourself or your company in Qt 5 development, please join the Qt contributor summit in Berlin, June 16-18. This is the main place where we would like to discuss the plans and ideas we have for Qt 5.0 and 5.1 together with you. Some of us will also be at the Ubuntu developer summit this week and the MeeGo conference later this month.

Vision

Qt 5 should be the foundation for a new way of developing applications. While offering all of the power of native Qt using C++, the focus should shift to a model, where C++ is mainly used to implement modular backend functionality for Qt Quick.

With Qt 5 we should put Qt Quick into the center of Qt without being disruptive for existing code developed for Qt 4. It will rather be a restructuring that will allow us to change the way we will think about application development in the future.

While traditional Qt/C++ applications will continue to work with Qt 5, there will be some fundamental changes on how applications can and will be written.

We should expect that over time all UIs will be written in QML. JavaScript will become a first class citizen within the Qt community and we should expect that a lot of application logic and even entire applications will be written in JavaScript instead of C++. The expectation is that many application developers will actually start out with QML and JavaScript and only implement functionality in C++ when required. For those specific use cases, the full power of the C++ APIs offered by Qt can be used to implement time critical and complex application functionality.

While we propose keeping the QWidget based programming model and API set available for compatibility, long term we also see QML as the future for user interfaces on the desktop. The solution here will most likely be QML-based component sets that integrate with the native styling APIs on the desktop platforms.

Four big architectural changes:

1. Re-architecture our graphics stack
   We will put Qt Quick and the QML Scenegraph into the center of our new graphics architecture. QPainter will still be available and is very useful for many things, but it won’t be used for the main user interface. Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph (not the scene graph on top of QWidgets as is currently done with Qt 4).
2. Base all Qt ports on Lighthouse
   The Lighthouse project was started with the goal of providing a better way to abstract the window system integration than we currently are using. It’s now reaching maturity with Qt 4.8, and we intend on using it exclusively for all Qt ports in Qt 5.0.
3. Modular repository structure
   A lot of this work has been done over the last weeks and you can see the results in the new modular Qt repositories. The modularization of Qt will facilitate and speed up the possibility to integrate contributions to Qt.
4. Separate all QWidget related functionality into its own library
   While the QWidget based classes are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term.

As you have seen from previous blog posts, the first three points have been worked on for quite some time and we’re starting the work on the last one right now. We do expect to have most of these changes done before August.

Qt Components and Qt Mobility will become more integral parts of the Qt platform and not be modules with a special status anymore.

Beta quality code available towards the end of 2011. Final release in 2012

Since we don’t believe we should change too many of Qt’s fundamentals, and the fact that we want to make it easy for existing applications to move to Qt 5 require us to be careful with the amount of changes we do to our existing code base. Many of the changes we are proposing and have started working on are about restructuring our code base into a new modular structure where every shared library lives in its own repository. We believe we should remove a few very rarely used APIs where keeping compatibility would block our way into the future. We think we will have beta quality code available towards the end of the year and final Qt 5.0 release some time during 2012.

Last week’s released Qt SDK with updates are planned to be used for the coming year to target Nokia Symbian and MeeGo devices. Qt 5.0 is focused around next generation application and UI development while still making it easy for apps developed with the Qt SDK to move to Qt 5.

Help us speed up the development

For those of you interested in some more details, here’s a link to a whitepaper describing some of the ideas in more detail. None of it is set in stone, but it reflects our current thinking.

You can also follow our work in the set of modular Qt repositories. We intend on keeping the master branch usable at all times on at least Linux with both Wayland and X11 (xcb lighthouse plugin). Work on getting things up and running on Mac and Windows has started, but it’ll probably take a little while before these ports become usable again.

We are all extremely excited about doing this renewal of Qt together with you. We believe that some features will not be fully in place in Qt 5.0 and will only come over time in subsequent releases, but we believe it will be possible to not have any significant feature regressions to Qt 4.8 (yes, we intend to release one more minor version in the Qt 4.x series within the next couple of months!). While developing Qt 5 we must do our very best to maintain source compatibility with Qt 4, so that moving your application over to Qt 5 will be as simple as possible. So if you want to help out or get involved yourself in Qt 5 development, why not meet up with us at the coming to the Qt Contributors Summit in Berlin this June.

UPDATE: Responses to Qt 5