The Future of Qt as a C++ API

ben.cottrell

I like how Quick enables the creation of creating graphics more quickly and efficiently, but, especially with the 3D features exposed through the Qt Quick 3D QML module, I wish I could access the same features in C++ more easily.

The tooling for Quick still doesn't seem mature, and seems to regress. I can remember having a stable enough design tool for QML files, in an older version of Creator for Qt 5.15 LTS. Now, I just write QML by hand, because the design tool in Creator is too unstable.

I don't want the user experience for C++ developers to decline, because more focus is given to Qt Quick. I started using Qt, because it was a market leader in cross-platform C++ GUI frameworks, as well as being free and open-source.

Am I being unreasonable, and, what are your thoughts/suggestions on the future of Qt?

sbela

I have the same problem with Quick, that the company forces me to use a separate app for designing the UI which has a lot of feature I do not need in the first place and needs a steep learning curve to create simple applications. I have to say that I am using Qt for simple tool apps which I use in Windows/Linux/Android, so maybe I am wrong. They targeted the big projects with the separate Designer app! The designer inside QtCreator have problem finding files/dependencies which was created inside one project, added/created inside the IDE.
This is why I create my gui without a designer and test by running the app. But I am lucky that I do not create complicate GUI-s.

Axel Spoerl

I am working for Qt and also use it in a couple of personal projects.
MuseScore is a really complex desktop application. The UI uses Quick and it's mainly written in QML. That comes with the advantage, that you can separate UI design (even if still written manually) from heavy lifting done in C++ extensions of QML. IMHO that's where the power lies: You can use Quick that works on mobile devices and desktops. A UI developer may have a more intuitive experience using QML, than C++. You still have all C++ APIs to extend QML where needed.

When I develop smaller apps (lately a VPN client), I just use widgets as I have done for years. They don't work so well on mobile devices, but they look great on a desktop. They are a full C++ API and the widgets designer in Creator is solid as a rock. Creator itself is a widgets application largely.

However, I would not recommend 5.15 LTS. That's outdated with its EOL scheduled end of this month. Better use 6.5, 6.8 or even 6.9.

I don't know of any plans to retire our C++ APIs. I personally think, that's not gonna happen.

ben.cottrell

@Axel-Spoerl said in The Future of Qt as a C++ API:

I am working for Qt and also use it in a couple of personal projects.
MuseScore is a really complex desktop application. The UI uses Quick and it's mainly written in QML. That comes with the advantage, that you can separate UI design (even if still written manually) from heavy lifting done in C++ extensions of QML. IMHO that's where the power lies: You can use Quick that works on mobile devices and desktops. A UI developer may have a more intuitive experience using QML, than C++. You still have all C++ APIs to extend QML where needed.

Other IDE's, such as Android Studio, and Microsoft Visual Studio have had stable design tools for much longer than Quick's existence. Luckily QML syntax is simple enough, that, I don't need to use a separate design tool to generate code I can paste into my implementation. I do the latter for Widgets (using the widget designer program). Even though QML code can be easier to write, than instantiating widgets inside QLayout's in C++, I think designers would like to have a drag-and-drop capable design tool, within the same IDE. That helped me, when I was learning Visual Basic and C#; the Windows Forms designer was really intuitive, and I could quickly double-click on events in the property editor to add event handlers in the code.

When I develop smaller apps (lately a VPN client), I just use widgets as I have done for years. They don't work so well on mobile devices, but they look great on a desktop. They are a full C++ API and the widgets designer in Creator is solid as a rock. Creator itself is a widgets application largely.

However, I would not recommend 5.15 LTS. That's outdated with its EOL scheduled end of this month. Better use 6.5, 6.8 or even 6.9.

Neither would I, as I am using at least version 6.5, especially if I want to use private API's in 6.9 for the RHI.

I don't know of any plans to retire our C++ APIs. I personally think, that's not gonna happen.

I don't doubt that, but, Qt 3D is no longer maintained by KDAB, and, as with controlling the rendering pipeline with RHI, the C++ API's were private. My concern is that this might become the norm, as QML is touted as being more convenient, without having accessible equivalents in C++.

SimonSchroeder

I use Qt as a cross platform library for desktop applications. That's why I am still using QWidgets and not QML. Also, I do understand the use of QML for larger companies that have separate designers (we don't), but for the common C++ programmer it is not actually necessary. As a C++ programmer I would certainly support being able to use QML widgets right from C++ without actually requiring QML at all).

As @Axel-Spoerl already mentioned it is unlikely that QWidgets will be abandoned any time soon. Even if it does happen, I am not to concerned. It would be still possible to continue open source development of a Qt fork. There have been interesting forks in the past (based on Qt 5). Verdigris (https://github.com/woboq/verdigris) tries to get rid of moc (by using macros) and still be ABI compatible with Qt. CopperSpice (https://www.copperspice.com/) takes a slightly different route and tries to use proper C++ code instead of macros. It is not ABI compatible with Qt. Also, they have reimplemented a few things which means it has diverged from Qt and you cannot just compile Qt code using CopperSpice anymore (I believe this worked initially).

With the advent of reflection in C++26 (and hopefully more reflection features in C++29 that make it more usable) I do hope to see a change in Qt or something derived from it. This would certainly help us to get rid of the moc for good (without sacrificing any of the beloved syntax).