Responses to Qt 5

It’s great to see so much feedback coming in about my Qt 5 blog two days ago. We’ve read and gone through all the comments, but it’s easier to try to answer the questions and concerns in a follow-up post rather than replying to comments.

We have now created a mailing list for discussions about Qt 5. If you’re interested, please consider subscribing. This will allow us to have better and more structured discussions around Qt 5 than replies to a blog post.

As far as I can see the main concerns can be grouped into a few categories. I’ll try to answer these from my point of view.

QML/JavaScript versus C++

There were a lot of reactions to the statement that we would like to make JavaScript a first class citizen for application development. What we are talking about here is adding another option, not removing C++. Qt is in its heart a C++ framework and this will not change. Quite to the opposite, I see C++ as continuing to be extremely important. There are many use cases where you need to be able to write native code.

So we will continue to add new C++ APIs and improve our existing C++ APIs to give you all the power and options one expects from a native framework. On the non graphical side (ie. QtCore, Network, database, etc.) nothing really changes, and on the graphical side we for now simply add another option.

That being said, we do believe that Qt Quick is the better technology for creating user interfaces. Right now, it still misses some things that developers (esp. on desktops) need. But once we combine what e.g. ListView with the desktop components Jens has been prototyping we do have a pretty good offering for many desktop use cases. But the goal is certainly to improve this over time and we believe this will make everybody’s life easier in creating compelling, modern looking applications.

JavaScript fits in naturally here, as QML is syntactically an extension to JavaScript. Being able to write or prototype parts of your application logic in a scripted language makes many things easier. Remember that this is a choice Qt wants to offer, not a requirement.

As to those asking for other scripting languages: No, we don’t intend to integrate these into Qt or QML. There are many reasons for that, but the simple ones are that it would seriously complicate the Qt Quick architecture and it could slow us down. It’s better to do one language and do it really well than to have something that will in the longer term become unmanageable. Having one consistent offering for developers is also very important here. Multiple scripting languages would just be confusing. JavaScript was chosen, because there are extremely high performant engines out there, because the basics of the language are very similar to what our developer base is used to from C++, and because it has the widest user base of all scripting languages out there.

QWidget and QGraphicsView

The QWidget-based classes will not suddenly disappear. Neither will they suddenly stop working. The exact goal with moving them into a separate module is to ensure our efforts on Qt Quick/QML will not cause problems for these classes. We ourselves intend on continuing to use them in Qt Creator and other applications for the foreseeable future.

We also don’t believe there will be bigger performance problems using these classes once we have re-architected the graphics stack in Qt. They might even become a bit faster on some of the platforms (but that’s a subject for a post of its own). Remote X11 connections is a use case that might get a slight hit. However, the trend in the industry has been moving away from X11 anyway. If there’s a strong interest by a group of people to support this use case, there is an opening to pick this work up and integrate with technologies such as NX. With the Lighthouse architecture, this might be just one plug-in away.

Together this means that there is no need for you to start worrying about having to rewrite the UI of your application in Qt Quick. But again, we believe strongly that it will in the longer term become the better and easier option compared to QWidgets.

Requiring OpenGL

As stated in the post we will require OpenGL 2.0 support for Qt 5 (Desktop GL or GL ES). The reason is simply that this gives a much better common ground for application developers. It also helps to significantly simplify our internal architecture.

We went through all the same concerns that I saw in responses to the blog post about having it as a requirement. In the end we came to the conclusion that it would be the best path forward and should not pose a real problem to most of our users.

On Mac and Windows this should not cause any real problems. Mac OS X has good OpenGL support on all their devices. On Windows we can use the ANGLE library to translate OpenGL ES to DirectX if it turns out that there are issues with native GL support.

On Linux desktops the recurring problem is the quality of some of the drivers. This is unfortunately a bit outside of our scope to get solved. But there is an alternative being worked on by the community that can be as good (or better) than our current Software rasterization: Mesa with llvmpipe. Having GL available consistently on Linux would be a tremendous improvement to the whole Linux stack.

The last part is low end hardware/embedded systems without a GPU. We are seeing that these systems are going away fast and that the price different between SoC’s with and without GPU is becoming very small. Given the great advantages a GPU offers to the achievable user experience and the fallback option to software GL outlined above, we believe it’s better to bet on OpenGL here as well.

Other things

We’re looking into some of the other features that have been asked for (like better C++11 support), but please remember that Qt 5.0 is not the end of the line and we will have 5.x releases where many of these improvements can then come in.

For 5.0 we have to carefully limit the scope of what we do. We will be working hard to not break anything that doesn’t need to be broken, and we’ll also be working to get 5.0 out in a timely manner.