Qt 5, C++ and Qt Widgets
We have seen the many questions and the concerns raised about our commitment to C++ and QWidget in Qt 5. I thought now would be a good time to address some of these concerns in this post.
The post on the Qt 5 alpha was focused on the new things we enable and add with Qt 5.
Let me just state it very clearly here:
QWidget and all derived classes are a core part of Qt 5 on the Desktop.
You can continue writing your application in exactly the same way as you have been doing with Qt 4.x.
We have promised to try to keep as much source compatibility with Qt 4.x as we can. And of course this includes QWidget and your application written in C++. This is not going away. Yes, the Qt Widgets module we have in Qt 5 is right now marked as ‘done’, which means we don’t have anybody actively working on new features for the module at this point in time. But this can change any day if someone has some interest or need to do more active development in this area.
What we did with Qt 5 is to add a new way to do applications with QML. I personally believe that over time we will see more and more apps being written that way, as I believe it is the better solution in the long term.
New user interfaces such as the Windows 8 Metro UI are not things we could simply add to our existing QWidget infrastructure. Adding support for the kind of animations used in these user interfaces is extremely difficult using QWidgets, as they were designed for the mostly static user interfaces that predominated until a couple of years ago.
The fluid animated user interfaces that are already there on Devices such as smartphones and tablets are now also starting to appear also on desktops. And they are simply not implementable using the QWidget infrastructure.
This implies that we needed to do something new here. And QML/Qt Quick was the answer we came up with to solve this problem. That’s why we’re investing in that area.
Our experience with QML over the last years has shown us that it is the superior technology for building UIs in the long term. If you want, you can simply use it as a more powerful replacement to .ui files. But you can also write some application logic in there using Javascript if you want.
It really is up to everybody what they make out of the options being given by Qt 5, and how they best like to use them.
C++ is and will stay our main programming language.
We have done significant work for Qt 5 adding many new C++ APIs. We have added support for C++11 in many places. And we’ll continue to do so, because larger scale applications written with Qt will be mostly written in C++ for a long time to come. And there’s nothing bad about this.
What we did with Qt 5 is to add another option into the mix. We want to make the usage of Javascript supported as well as C++ is supported. We are not making it the superior way or even the only way. That is a good thing, as it opens up new options for how you write your application.
If you want, you can do smaller pieces of application logic inside QML. It allows to do some rapid prototyping that can then be replaced by C++ in the final implementation. It gives you abilities to do application scripting. And for many apps it also gives you the option to write a big part of it in QML and Javascript.
Summary
With Qt 5, if you want to use Qt as you have always used it, please go ahead. It’s a fully supported way of doing things.
But I do believe that we will need more then what we have in Qt 4 for the longer term future. The expectations towards application UIs are changing drastically, especially when creating consumer-facing apps.
We need to have solutions available if we want Qt to stay relevant. That’s what Qt 5 is all about.
Cheers,
Lars
