Qt Creator 12 Released(qt.io)
qt.io
Qt Creator 12 Released
https://www.qt.io/blog/qt-creator-12-released
89 comments
Okay, this makes me think of QTBUG-56214, which has to do with Qt Creator suddenly not recognizing mouse scroll wheel events after a while. (often as a result of various device state changes common if you use a KVM on your machine)
Been following the issue for years, apparently it was marked as fixed a few months ago, but the issue is clearly still there. I wonder if this latest Qt Creator update will finally incorporate the fix, or if its not really fixed.
Been following the issue for years, apparently it was marked as fixed a few months ago, but the issue is clearly still there. I wonder if this latest Qt Creator update will finally incorporate the fix, or if its not really fixed.
Hey, it's open. It can be forked.
If anyone is willing to maintain a frozen branch (preferably one of those where Designer still worked), I want to know.
If anyone is willing to maintain a frozen branch (preferably one of those where Designer still worked), I want to know.
Honestly the open-source community is one of the most unironically capitalist communities we have. Do devs have social responsibility? Nope, fork it. Do devs have a responsibility to take input from the people their product has locked in? Nope, fork it. Do devs have a responsibility to maintain what they produce & present? Nope, fork it.
If only forking it was a good answer, we'd have solved so many by now.
If only forking it was a good answer, we'd have solved so many by now.
The Qt company has been somewhat hostile to the spirit of open source (see the drama around closing the Qt library for a year since release), so I'm not sure how close it is to the canonical core of the community, and especially to any obligations that might come from that.
Either way, there is no mechanism for accountability in open source other than peer pressure or reputation. Qt Company doesn't care about that a lot. They care about making buck first and foremost, operating in the "capitalist" realm. So the solution I propose is using that playbook too.
In a broader view, forking is telling people "you are not our devs any more, we're seizing the means of production", which I think is rather anti-capitalist.
Either way, there is no mechanism for accountability in open source other than peer pressure or reputation. Qt Company doesn't care about that a lot. They care about making buck first and foremost, operating in the "capitalist" realm. So the solution I propose is using that playbook too.
In a broader view, forking is telling people "you are not our devs any more, we're seizing the means of production", which I think is rather anti-capitalist.
They should just give up and add the features that are compelling to Code via extensions.
I love Qt Framework, but the entire project has this weird entrenchment around using UIC or QML which are both designed to be some sort of templating for easily creating apps.
However when actually writing code this stuff is practically magic which was confusing for me to learn about.
I found it much quicker and logical to just write the classes and register your widgets/components in the C++ class constructor than use these magic files which rely on nested XML/JSON. The entire point of these files is to make building an app seem easy (even easier than HTML + JS) but I find the entire thing confusing and overly engineered when you really need to write and reference logic.
However when actually writing code this stuff is practically magic which was confusing for me to learn about.
I found it much quicker and logical to just write the classes and register your widgets/components in the C++ class constructor than use these magic files which rely on nested XML/JSON. The entire point of these files is to make building an app seem easy (even easier than HTML + JS) but I find the entire thing confusing and overly engineered when you really need to write and reference logic.
I might be misunderstanding something but last I played with it, it seemed like the stock QML controls were extremely barebones and required either rolling your own or pulling in a library of third party QML controls for pretty basic stuff, which is a bit strange compared to the the range of controls provided by Qt Widgets and a turnoff for anybody looking for something a little more “batteries included”.
IDK About bare QML, but for desktop apps QQC2/Kirigami is pretty great.
https://develop.kde.org/docs/getting-started/kirigami/
https://doc.qt.io/qt-6/qtquickcontrols-index.html
The QML types are pretty extensive, covering most of the Widgets I think:
https://doc.qt.io/qt-6/qmltypes.html
For Widgets-consistent styling:
https://invent.kde.org/frameworks/qqc2-desktop-style
https://develop.kde.org/docs/getting-started/kirigami/
https://doc.qt.io/qt-6/qtquickcontrols-index.html
The QML types are pretty extensive, covering most of the Widgets I think:
https://doc.qt.io/qt-6/qmltypes.html
For Widgets-consistent styling:
https://invent.kde.org/frameworks/qqc2-desktop-style
> I might be misunderstanding something but last I played with it
I'd say this is a fair description of a point in the past, but these days Qt Quick Controls 2 (which is bundled) is fairly well-featured, and they do keep adding new features release-by-release. It's not far from parity with Qt Widgets, and some things it does significantly better (e.g. animation or complex input handling).
I'd say this is a fair description of a point in the past, but these days Qt Quick Controls 2 (which is bundled) is fairly well-featured, and they do keep adding new features release-by-release. It's not far from parity with Qt Widgets, and some things it does significantly better (e.g. animation or complex input handling).
I have very little experience with QML but from what I saw was that it was more barebones than widgets and offered little advantage over UIC which I also don’t use for the reasons stated above.
Officially, There were QtQuickControls: https://doc.qt.io/qt-6/qtquickcontrols-index.html . No one i knew really cared for them though.
Most of the time, QtQuick was meant to target embedded/mobile world, while QtWidgets - desktop. QtQuickControls 1.0 have been a dumpster fire anyway. So we had to write our own for performance reasons. QtQuickControls 2.0 were a bit of a licensing headache iirc. (Most of the companies i worked for stuck with Qt5.6 for licensing reasons).
Most of the time, QtQuick was meant to target embedded/mobile world, while QtWidgets - desktop. QtQuickControls 1.0 have been a dumpster fire anyway. So we had to write our own for performance reasons. QtQuickControls 2.0 were a bit of a licensing headache iirc. (Most of the companies i worked for stuck with Qt5.6 for licensing reasons).
Qt Quick Controls still exist and are supported and actively developed - in the 2.x version range, since 2016.
Yeah but they were officially released with Qt 5.7 no? iirc they had a different license too. LGPL v3 was a problem for most of the companies i worked for back then. None of them purchased a commercial Qt license. The situation was so weird that even during 2021, they were just using Qt 5.6. Slowly they started moving away to Electron and other tech. (devs were cheaper/easier to find).
The closest thing to QQC 2.0 we had was something called QSkinny. Every Qt < 5.6 project I worked on, we ended up reimplementing the same common widgets. 4-5 times. I lost track of things after that.
The closest thing to QQC 2.0 we had was something called QSkinny. Every Qt < 5.6 project I worked on, we ended up reimplementing the same common widgets. 4-5 times. I lost track of things after that.
QML is not "magic". It's a separate language that integrates with C++ and makes UI design easier, sort of like how webpages use HTML/CSS for the graphics and JS for the logic.
When it is unclear how my app compiles this separate language together with C++ it is magic. When I attempt to write an application and someone says “use this other language and don’t worry about the implementation details” that appears as magical to the implementer.
Magic can be de-obfuscated with documentation but if I can accomplish the same thing in C++ with nearly the same amount of code, then the magic isn’t for me and C++ is a lot more clear and reduces cognitive overhead.
Magic can be de-obfuscated with documentation but if I can accomplish the same thing in C++ with nearly the same amount of code, then the magic isn’t for me and C++ is a lot more clear and reduces cognitive overhead.
So you always look at the generated Assembly to understand the magic behind producing a native executable, and the magic behind unrolling for loops into sequences of AVX512 instructions, or the magic behind inlining a virtual method dispactch,...?
> but if I can accomplish the same thing in C++ with nearly the same amount of code
That's not the case when it comes to QML/QtQuick though. It sounds like you were writing a desktop application, So C++/QWidgets were probably a better choice for your use case. But for embedded/mobile use cases, where reactive, smooth animated user interfaces are the norm, QML is on an entirely different league.
Also, with QML I didn't have to worry about the ugly combination of junior engineers and C++ footguns.
That's not the case when it comes to QML/QtQuick though. It sounds like you were writing a desktop application, So C++/QWidgets were probably a better choice for your use case. But for embedded/mobile use cases, where reactive, smooth animated user interfaces are the norm, QML is on an entirely different league.
Also, with QML I didn't have to worry about the ugly combination of junior engineers and C++ footguns.
I've been working on a team replacing a widgets UI with QML, everyone on the team loves QML and finds it way easier/faster to work in (and the design/management love all the smooth animations etc.)
and the guy who sucks at C++ breaks things less
and the guy who sucks at C++ breaks things less
Yeah that's more or less how it was for us too. Do make sure QML has all that you need. On Desktop (this was back in 2018, so ymmv), things like table view, undo redo stack, other integration features were missing.
Our journey was like: "Wow.. this is so nice and easy.".. 70% later.. "Should have researched this better. Now we have to mix QWidgets with QML code to get what we want".
Our journey was like: "Wow.. this is so nice and easy.".. 70% later.. "Should have researched this better. Now we have to mix QWidgets with QML code to get what we want".
I’m working in mobile too but have no use for smooth animations (which is of very little value) so QML isn’t really valuable. I also do not like the idea of embedding a browser stack and forced to write JS just for that purpose. The point is to keep my code in C++ and not hop around to x different files to make sense of my application.
QML is NOT a browser stack though. QML is just a way for you to script QObjects. QtQuick - on the other hand - is a very performant GPU accelerated scenegraph that can be scripted using QML.
> The point is to keep my code in C++ and not hop around to x different files to make sense of my application.
Another point of view that differs from this is - QML lets you easily separate UI logic from business logic, to better make sense of your application. Especially when it comes to "responsive applications". For eg. All the UI related parts of your application stay in QML files in folders like desktop/ android/ common/ etc... All the "backend logic" stays in C++, ready to be used by all these UI elements.
It is not about being forced to write JS. Nothing stopping you from writing very declarative looking C++ either (fun article: https://woboq.com/blog/property-bindings-in-cpp.html ). It is just about using a better tool for the job. State machines. Reactive properties. Declarative UI description. All of these make you need a lot less code than writing everything in imperative c++.
> The point is to keep my code in C++ and not hop around to x different files to make sense of my application.
Another point of view that differs from this is - QML lets you easily separate UI logic from business logic, to better make sense of your application. Especially when it comes to "responsive applications". For eg. All the UI related parts of your application stay in QML files in folders like desktop/ android/ common/ etc... All the "backend logic" stays in C++, ready to be used by all these UI elements.
It is not about being forced to write JS. Nothing stopping you from writing very declarative looking C++ either (fun article: https://woboq.com/blog/property-bindings-in-cpp.html ). It is just about using a better tool for the job. State machines. Reactive properties. Declarative UI description. All of these make you need a lot less code than writing everything in imperative c++.
It’s not a browser stack but includes an HTML painter and V8 engine in your project? This sounds pretty close to a browser stack to me. If this isn’t true then this is one of the confusing aspects. In including pieces of a browser stack or whatever is going on doesn’t really help it make it look not like one. It seems like the ideas are obfuscated just to call it something else.
HTML painter? you mean how QLabel supports rich text via. HTML tags?
Not sure what you are getting at with the "ideas are obfuscated to call it something else". You'd have a widget tree/graph even with QWidgets/QObjects. Would you call any QWidget program that uses QJsEngine "a browser stack"?. QML is just a declarative programming language, that lets you script QObject properties/react to signals/property changes.
QtQuick is a scenegraph that uses QML to render a GPU accelerated UI. Which is what is needed on embedded/mobile UIs to get smooth high performant animated GUIs. That'd be too ineffecient and cumbersome to accomplish with QWidget/C++.
Not sure what you are getting at with the "ideas are obfuscated to call it something else". You'd have a widget tree/graph even with QWidgets/QObjects. Would you call any QWidget program that uses QJsEngine "a browser stack"?. QML is just a declarative programming language, that lets you script QObject properties/react to signals/property changes.
NumberInput { id: width }
NumberInput { id: height }
Label {
text: "Area value is: " + width.value * height.value // automatically gets updated
}
QtQuick is a scenegraph that uses QML to render a GPU accelerated UI. Which is what is needed on embedded/mobile UIs to get smooth high performant animated GUIs. That'd be too ineffecient and cumbersome to accomplish with QWidget/C++.
In QWidget if you use it then it’s compiled into the application. If you use QML it’s always there as far as I understand. Please review this post which seems to indicate that JS and HTML components are added to a project when QML is used.[0] It may not be a full engine but as I’ve previously stated I’m not interested in writing things in multiple languages. I want as few extra languages as possible. To tell me it’s not a browser stack then go on about how to use QML you can declare pages in HTML and JS that are then compiled into the binary that passes data between C++ and JS is entirely ignorant of my initial goals. If I wanted to use browser technology and JS I would build my app for a browser.
> To accomplish the same in pure C++, you'd need to implement some kind of observer pattern/manually connect signals and slots across objects to allow for updates of dependent values (Label's text).
I do not find that extra work because it’s represented in the class itself and the observer pattern maintains my preferences.
Perhaps these technologies are useful for those who want to quickly write a mobile app with slick animations. Indeed it is a easy way for Qt to gain audience for those types of apps especially for people who aren’t able to learn C++. For my intentions I am looking for less overhead overall to keep files as pure C++ as possible to ensure that a class I’m writing represents the full scope of it’s functionality and domain.
[0] https://news.ycombinator.com/item?id=38395603
> To accomplish the same in pure C++, you'd need to implement some kind of observer pattern/manually connect signals and slots across objects to allow for updates of dependent values (Label's text).
I do not find that extra work because it’s represented in the class itself and the observer pattern maintains my preferences.
Perhaps these technologies are useful for those who want to quickly write a mobile app with slick animations. Indeed it is a easy way for Qt to gain audience for those types of apps especially for people who aren’t able to learn C++. For my intentions I am looking for less overhead overall to keep files as pure C++ as possible to ensure that a class I’m writing represents the full scope of it’s functionality and domain.
[0] https://news.ycombinator.com/item?id=38395603
> [0] https://news.ycombinator.com/item?id=38395603
In that post, I was just drawing a parallel to try and compare QML with some other better known technology. My point was not to say that it is actually HTML that goes into the program. I'm sorry if it caused confusion. My message was meant as a bird's eye technology comparison, ignoring the fine details.
A different, more to the point take is: just like a web browser reads HTML and ends up interpreting a visual representation of a page, the QML engine will read a QML file and end up with a hardware-accelerated visualization of it.
Qt just gives you the tools for that.
If you don't need a hardware-accelerated rendering of a UI, working smoothly at 60fps in consumer devices, then probably QML wouldn't bring much to the table anyway.
In that post, I was just drawing a parallel to try and compare QML with some other better known technology. My point was not to say that it is actually HTML that goes into the program. I'm sorry if it caused confusion. My message was meant as a bird's eye technology comparison, ignoring the fine details.
A different, more to the point take is: just like a web browser reads HTML and ends up interpreting a visual representation of a page, the QML engine will read a QML file and end up with a hardware-accelerated visualization of it.
Qt just gives you the tools for that.
If you don't need a hardware-accelerated rendering of a UI, working smoothly at 60fps in consumer devices, then probably QML wouldn't bring much to the table anyway.
> In QWidget if you use it then it’s compiled into the application.
Same thing with QML. QML files get compiled into the application. The QQmlEngine then interprets various expressions/actions at runtime. Just like scripting a QWidget/QDeclarativeView based application with QtScript.
I think the post you have linked to was simply comparing QML as a language to a HTML and how Javascript can be used as glue code to script various actions, and how you can expose business logic to javascript via. FFI.
I know where you're coming from. What I am saying was it is less about preferences and more about separation of concerns. "What the UI should look like" vs. "What the UI should do". The latter usually needs to happen in C++ anyways. But the former - there are better tools/ways to describe that.
Most of the time "What the UI should look like" probably gets described in your constructors. It probably takes a few write/compile/test iterations to get what you want. That works well enough for simpler uis. When things get more complex... that's when other tools can simplify your work. With UIC, you (or an actual designer) can visually edit the ui in QtDesigner and give you the ui files. All the UI description gets compiled to it's own class. Your business logic code wouldn't have to worry about details of layouts, positions, colors etc... It wouldn't have to be modified whenever you want to change the position of a button.
fwiw I started appreciating the designer only after going back to writing QWidgets code after a few years of break
Same thing with QML. QML files get compiled into the application. The QQmlEngine then interprets various expressions/actions at runtime. Just like scripting a QWidget/QDeclarativeView based application with QtScript.
I think the post you have linked to was simply comparing QML as a language to a HTML and how Javascript can be used as glue code to script various actions, and how you can expose business logic to javascript via. FFI.
<button />
Button { onClick: console.log('hello') }
Button *button = new Button(parent);
connect(button, &Button::clicked, [](){ qDebug() << "hello" });
I know where you're coming from. What I am saying was it is less about preferences and more about separation of concerns. "What the UI should look like" vs. "What the UI should do". The latter usually needs to happen in C++ anyways. But the former - there are better tools/ways to describe that.
Most of the time "What the UI should look like" probably gets described in your constructors. It probably takes a few write/compile/test iterations to get what you want. That works well enough for simpler uis. When things get more complex... that's when other tools can simplify your work. With UIC, you (or an actual designer) can visually edit the ui in QtDesigner and give you the ui files. All the UI description gets compiled to it's own class. Your business logic code wouldn't have to worry about details of layouts, positions, colors etc... It wouldn't have to be modified whenever you want to change the position of a button.
fwiw I started appreciating the designer only after going back to writing QWidgets code after a few years of break
I think it doesn't include a V8 engine anymore. Qt has its own JS implementation as far as I know. And it doesn't have a full html painter
(If you don't use QtWebEngine)
Initially QmlEngine used to use v8 for the javascript interpreter around Qt 5.0. They quickly migrated away from that to their own interpreter for various reasons: https://forum.qt.io/topic/32701/qt-v8/4
C++ is not the language for GUIs on mobile. There’s not a single mature, widely adopted framework that supports C++ for laying out widgets/views/GUI elements.
Where it is that you see "magic"? QML is a markup language (just like HTML is for web) which can have inline code in it (JavaScript). These QML files are quite literally embedded into the binary, loaded in-memory at runtime, and processed by a rendering and execution engine. Quite similar to how a web browser would render HTML and execute JS code. In fact, the latter in QML originally was done by V8 itself!
The extra feature of the QML engine wrt. a web browser is to provide callbacks and hooks, doing what I guess we could call FFI, allowing for events and function calls to travel between C++ and JS. Complex, but not much sort of magic in there.
As far as I understand, we would draw a parallel between QML and what Tauri does. It just embeds a whole interpreter into your program, in order to be able to draw the markup and run the scripting.
The extra feature of the QML engine wrt. a web browser is to provide callbacks and hooks, doing what I guess we could call FFI, allowing for events and function calls to travel between C++ and JS. Complex, but not much sort of magic in there.
As far as I understand, we would draw a parallel between QML and what Tauri does. It just embeds a whole interpreter into your program, in order to be able to draw the markup and run the scripting.
For a beginner to Qt (not necessarily programming. not even C++. Just Qt.), most of this tends to be magic though.
The build system automatically embeds all the QML files into the program binary. The QObject system transparently adds reflection to C++, using the build system. The QmlEngine that keeps track of properties that are in use and automatically updating the dependent values, and the headaches that come with broken bindings.
Not saying it is a big deal to learn or anything, but a lot of this stuff is not what "traditional C++ devs" are used to. I had to teach some new devs "Intro to Qt for C++ progammers", so i got to see this from their perspective.
The build system automatically embeds all the QML files into the program binary. The QObject system transparently adds reflection to C++, using the build system. The QmlEngine that keeps track of properties that are in use and automatically updating the dependent values, and the headaches that come with broken bindings.
Not saying it is a big deal to learn or anything, but a lot of this stuff is not what "traditional C++ devs" are used to. I had to teach some new devs "Intro to Qt for C++ progammers", so i got to see this from their perspective.
But that's a knowledge issue. Which is fine, if I can say one thing for sure is that none of us was born knowing anything at all :-)
C++ programmers would probably be used to lower level kind of technologies, but when talking about this I think it just helps to think about what would you do if you wanted to embed an HTML and JS file into your program and wanted it to work like QML works.
For an experienced C++ dev, a list of stuff will naturally start flowing through their mind:
* A mechanism to inject the files into the binary upon compilation.
* How to interpret the HTML and paint on the screen? We'll need an HTML rendering engine and a surface painter.
* About JS, how to run it? Well, maybe time to include V8 into the program. It will take care of running JS code.
* Now to make calls between both languages. Probably V8 already provides callbacks because it implements FFI already for you.
* And other stuff you mentioned, like a property manager that remembers what has been registered and creates change observers in order to trigger events for C++ to know.
Thing is, Qt already gives you all of this done, otherwise their proposal of QML wouldn't have gone too far...
These series of articles touch on the topic and can enlighten a bit about some details:
* https://www.kdab.com/qml-engine-internals-part-1-qml-file-lo...
* https://www.kdab.com/qml-engine-internals-part-2-bindings/
* https://www.kdab.com/qml-engine-internals-part-3-binding-typ...
* https://www.kdab.com/qml-engine-internals-part-4-custom-pars...
C++ programmers would probably be used to lower level kind of technologies, but when talking about this I think it just helps to think about what would you do if you wanted to embed an HTML and JS file into your program and wanted it to work like QML works.
For an experienced C++ dev, a list of stuff will naturally start flowing through their mind:
* A mechanism to inject the files into the binary upon compilation.
* How to interpret the HTML and paint on the screen? We'll need an HTML rendering engine and a surface painter.
* About JS, how to run it? Well, maybe time to include V8 into the program. It will take care of running JS code.
* Now to make calls between both languages. Probably V8 already provides callbacks because it implements FFI already for you.
* And other stuff you mentioned, like a property manager that remembers what has been registered and creates change observers in order to trigger events for C++ to know.
Thing is, Qt already gives you all of this done, otherwise their proposal of QML wouldn't have gone too far...
These series of articles touch on the topic and can enlighten a bit about some details:
* https://www.kdab.com/qml-engine-internals-part-1-qml-file-lo...
* https://www.kdab.com/qml-engine-internals-part-2-bindings/
* https://www.kdab.com/qml-engine-internals-part-3-binding-typ...
* https://www.kdab.com/qml-engine-internals-part-4-custom-pars...
> But that's a knowledge issue. Which is fine, if I can say one thing for sure is that none of us was born knowing anything at all :-)
It is just that for them, "non c++" tools ended up doing a lot of this magic work. Plus the idea of "embedding another language or two into a language where i already made UI without any fuss" tended to keep some of the more experienced C++ devs away from QML in my experience. Giving them tasks like animating the UI, writing custom styles etc.. that's where QML converted more C++ devs in my experience.
Those kdab blogposts were indeed very helpful for us back then.
It is just that for them, "non c++" tools ended up doing a lot of this magic work. Plus the idea of "embedding another language or two into a language where i already made UI without any fuss" tended to keep some of the more experienced C++ devs away from QML in my experience. Giving them tasks like animating the UI, writing custom styles etc.. that's where QML converted more C++ devs in my experience.
Those kdab blogposts were indeed very helpful for us back then.
The reality behind 'Magic' is always a 'Knowledge' issue ;-)
No offense to Qt but if I wanted any of that I’d write my app for a browser. There is very little benefit to write something that works just like a browser with extra overhead when I’m trying to write in C++.
That’s usually what people mean by magic, extra complexity that is not apparently beneficial even when partially understood.
That’s usually what people mean by magic, extra complexity that is not apparently beneficial even when partially understood.
There was still the 'moc' magic in the traditional Qt.
But the interesting question is can something like Qt be fully build in modern c++ without need for such magic?
But the interesting question is can something like Qt be fully build in modern c++ without need for such magic?
You need other magic. C++Builder does it via compiler extensions for properties/events instead of something like moc, so at least it’s a closer-to-code compilation.
One day it’ll be in C++ natively. PME (property, method, event) was proposed to the committee in 2002. Modern C++ uses a different approach, but as is common with current additions, it can be argued is far more verbose and clumsy.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n13...
Then of course Microsoft has their property (subset) syntax, Unreal Engine has their macros and build system, Qt has reflection and C++Builder the same via extended RTTI… everyone who needs this, whether it’s Qt, MS, Epic, Embarcadero, etc reinvents their own mostly overlapping wheels. And still in 2023 a solved problem has not made it into the standard. The most powerful in terms of width of features is C++Builder and I often wonder what would happen if Epic adopted a similar or the same pattern instead of using macros and preprocessing. Probably C++ would be forced to either split or adopt support for the features multiple companies need.
One day it’ll be in C++ natively. PME (property, method, event) was proposed to the committee in 2002. Modern C++ uses a different approach, but as is common with current additions, it can be argued is far more verbose and clumsy.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n13...
Then of course Microsoft has their property (subset) syntax, Unreal Engine has their macros and build system, Qt has reflection and C++Builder the same via extended RTTI… everyone who needs this, whether it’s Qt, MS, Epic, Embarcadero, etc reinvents their own mostly overlapping wheels. And still in 2023 a solved problem has not made it into the standard. The most powerful in terms of width of features is C++Builder and I often wonder what would happen if Epic adopted a similar or the same pattern instead of using macros and preprocessing. Probably C++ would be forced to either split or adopt support for the features multiple companies need.
Not until reflection comes to be.
Maybe with concepts + if constexpr + traits, if one is willing to open the druids metaprogramming book.
Maybe with concepts + if constexpr + traits, if one is willing to open the druids metaprogramming book.
There were a couple of attempts in that direction, but i haven't really seen them used in any production codebase.
https://woboq.com/blog/verdigris-qt-without-moc.html
https://woboq.com/blog/verdigris-qt-without-moc.html
https://ossia.io uses verdigris pretty much exclusively. Worse syntax but lots of advantages compared to moc.
What advantages?
- Ability to use latest standards without issues - for a long time moc's c++ parser choked on headers containing too recent C++ features, breaking the build. For instance I remember noexcept and [[attributes]] being quite problematic a few years ago.
Verdigris in contrast is just macros with c++17/20 code so it works and keeps working with newer standards.
- moc integration in build systems would also not work well, e.g. for a long time there were issues in cmake's automoc if two files had the same name in different folder of the same project.. gets kinda complicated when you have projects with multiple thousands of source files.
- I observed decreased build times after the switch
- It's just a couple headers, very easy to experiment with changes and improvements
Verdigris in contrast is just macros with c++17/20 code so it works and keeps working with newer standards.
- moc integration in build systems would also not work well, e.g. for a long time there were issues in cmake's automoc if two files had the same name in different folder of the same project.. gets kinda complicated when you have projects with multiple thousands of source files.
- I observed decreased build times after the switch
- It's just a couple headers, very easy to experiment with changes and improvements
Yes that’s what I’m saying you can build your software without this magic (moc, uic, qml) but it’s not clear that’s what is happening in the documentation for it. You simply just strip out the register for it in the proper files and then delete the xml or qml files.
A lot of this stuff gets further promoted in things like Qt Creator which relies on building these kind of meta definition files.
Moc is less of a problem IMO because it’s more related to C++ macros which at least is a language feature.
A lot of this stuff gets further promoted in things like Qt Creator which relies on building these kind of meta definition files.
Moc is less of a problem IMO because it’s more related to C++ macros which at least is a language feature.
> (...) weird entrenchment around using UIC or QML (...)
There is nothing weird about UIC or QML. These are essentially DSLs that help quickly designing and iterating iver user interfaces.
UIC quite literally just generates C++ from a XML description of a Widgets-based UI element. You work over the .ui file with a WYSIWYG editor, save it, and your qmake/CMake project generates the C++ that does what you told it to do.
This is basically the same approach follows by essentially all major GUI frameworks. Microsoft's XAML works like this, React's JSX too, Android has its layout files, etc.
I wonder what approach do you find better suited for the job.
There is nothing weird about UIC or QML. These are essentially DSLs that help quickly designing and iterating iver user interfaces.
UIC quite literally just generates C++ from a XML description of a Widgets-based UI element. You work over the .ui file with a WYSIWYG editor, save it, and your qmake/CMake project generates the C++ that does what you told it to do.
This is basically the same approach follows by essentially all major GUI frameworks. Microsoft's XAML works like this, React's JSX too, Android has its layout files, etc.
I wonder what approach do you find better suited for the job.
This article is about the Qt Creator IDE, not about the Qt Framework, though.
A very welcomed release. I love Qt. I'm building a note-taking app with an advance block editor (so you could write some text and have a Kanban in the same view). The model is in C++ and the view is built with QML and I absolutely love that combo. In less than 20 days I managed to have all the basics ready (including multi block selection, support for different block types, etc). You can check it out here: https://www.get-plume.com/.
I can't recommend Qt more!
I can't recommend Qt more!
Good to see QML being more ready for desktop use cases than what I remember...
Out of curiosity, what component library did you use with QML?
Nothing fancy, just the built-in ones. The rest I customize myself (very easy to do).
This is about the Qt Creator IDE, not about the Qt framework!
I use Qt Creator most days (version 10). It is a great piece of software. Although it seems rather slow recently (due to Clang-Tidy?).
We build meldstudio.co (a performance oriented desktop app) using Qt/QML and managed to entirely avoid Qt Creator. It’s like traveling back in time coming from a VS Code configured with clangd and LLDB debugger.
Really wish they would invest in getting QML LSP to a working state. It’s been in development for well over a year now and still not used by Qt Creator itself. qmlls is missing proper formatting support, syntax aware highlighting (although we paid a contributor to land this upstream over a year ago, the PR is still pending). It has unusable latency compared to other LSPs, the list goes on.
Really wish they would invest in getting QML LSP to a working state. It’s been in development for well over a year now and still not used by Qt Creator itself. qmlls is missing proper formatting support, syntax aware highlighting (although we paid a contributor to land this upstream over a year ago, the PR is still pending). It has unusable latency compared to other LSPs, the list goes on.
Anyone left stranded with Microsoft 's decisions regarding C++ GUIs, only has C++ Builder and Qt, as frameworks that combine C++'s capabilities with high productivity tooling like for Java and .NET.
And LeanQt of course.
You misspelled Electron.
I can't remember the last time I saw a new Qt app.
I can't remember the last time I saw a new Qt app.
The Telegram Desktop client is a Qt app as well. (and about ten times snappier than any other messengers desktop client)
The Tesla GUI in the car is made using Qt and it’s arguably one of the best. But I agree almost everyone go with Electron.
Eletron, when one cares more about themselves than their users. (TM)
That should be a shirt
Tesla using Qt for GUI while SpaceX uses Electron shows how crazy modern UI development has become.
As much as Tesla's well known for thumbing their nose at safety, Qt has variants designed for safety critical things like instrument clusters. Whoever owns Qt these days even calls out instrument clusters specifically.
Electron has none of that.
Electron has none of that.
Not to mention how slow Electron would run on the embedded CPU on the Tesla dash board.
The Intel atom is slow but the newer cars have an AMD Ryzen and it should run fine.
I sometimes wonder if the fancy SpaceX touchscreens are there just for the press, and when the cameras go off they use the real physical instrumentation backups that wouldn't die altogether with the wrong helmet bump in zero gravity.
Ditto Mercedes.
All KDE apps!
Linux user I guess.
Sadly QT designer is still a complete trainwreck that doesn't seem to have been updated in a decade. It's so sad because it could be very very useful, but the entire way it works just makes it hard to use. Adding widgets is messy, using them in code is messy, there's no way to combine both and see the results, the way you handle/modify the objects themselves is super unwieldy... it's no wonder why desktop GUIs are getting overtaken by web based apps.
The classic designer hasn't indeed been updated in a long time but the QtQuick one is much more powerful, allows live editing of the code and seeing the results side by side ..
https://youtu.be/jXe5Tkx3EZo
https://youtu.be/jXe5Tkx3EZo
Maybe because Qt Design Studio is what matters nowadays.
I wonder whether it supports normal (as in, vscode-like) tab switch behavior these days.
When I tried it a few years ago, it forced some history-based keyboard tab switching, rather than behaving like everything else.
When I tried it a few years ago, it forced some history-based keyboard tab switching, rather than behaving like everything else.
Qt itself is nice but C++ is just not the greatest language for building GUI apps.
I’d love to see support for Go or Rust. Go seems particularly well suited and would be extremely productive for this kind of programming.
I’d love to see support for Go or Rust. Go seems particularly well suited and would be extremely productive for this kind of programming.
Rust has quite decent support for QML though. One of the really famous video footage stabilizer apps uses Rust with QML: https://docs.gyroflow.xyz/app/technical-details/used-technol..., and that is a non trivial UI: https://gyroflow.xyz/
For Rust it's not that easy: Qt's basic model is a tree of widgets, where the parents know (and own) their children aaand the children also know their parents, which from what I understood creates ownership cycles (all handled automatically by Qt obviously but the Rust borrow checker cannot really be made aware of it). Basically a lot of ownership transfer happens behind the scene in Qt to make sure that things "just work" and that you don't have to call delete manually for each widget.
You’d probably use Arc or create a special custom smart pointer in Rust for use with the Qt paradigm. Simple references probably would not be expressive enough for Qt.
Qt objects have to be heap allocated anyway so you would not be adding much overhead. If you designed a specialized container it could probably be zero overhead.
Qt objects have to be heap allocated anyway so you would not be adding much overhead. If you designed a specialized container it could probably be zero overhead.
> You’d probably use Arc or create a special custom smart pointer in Rust for use with the Qt paradigm. Simple references probably would not be expressive enough for Qt.
Shoving Arc everywhere is a great way to leak memory with Rust. No, compiler doesn't prevent that. It is not a safety bug.
The problem is Qt has its own ownership model that goes against Rust's ownership model. It is a prime C++98 era library at its heart and it didn't change that much in the core architecture.
Moreover Qt relies on heavy use of inheritance-based OOP which is Rust also against.
So current Rust GUI libraries using Qt stuff like Slint has to implement a second level of abstraction and state tracking which costs performance.
I think the best way ahead is implementing a GUI library (at least the Widgets layer all the way down until rendering engine) in Rust. However I am not really hopeful. Writing GUI toolkits from scratch could be one of the hardest software engineering problems out there.
The days when benevolent software companies released open source full-featured GUI frameworks with relatively permissive licenses are mostly behind. Nokia didn't have much to gain from releasing Qt as LGPL but they did it anyway. I don't think today's big tech would do the same unless there is a clear, guaranteed way of monetizing it.
Dealing with N dimensional space of multiple OSes with multiple graphics APIs, multimedia engines, high DPI screens and complex text rendering is 90% painful software development. Somebody can do it but I don't think it will be open source, neither cheap.
Shoving Arc everywhere is a great way to leak memory with Rust. No, compiler doesn't prevent that. It is not a safety bug.
The problem is Qt has its own ownership model that goes against Rust's ownership model. It is a prime C++98 era library at its heart and it didn't change that much in the core architecture.
Moreover Qt relies on heavy use of inheritance-based OOP which is Rust also against.
So current Rust GUI libraries using Qt stuff like Slint has to implement a second level of abstraction and state tracking which costs performance.
I think the best way ahead is implementing a GUI library (at least the Widgets layer all the way down until rendering engine) in Rust. However I am not really hopeful. Writing GUI toolkits from scratch could be one of the hardest software engineering problems out there.
The days when benevolent software companies released open source full-featured GUI frameworks with relatively permissive licenses are mostly behind. Nokia didn't have much to gain from releasing Qt as LGPL but they did it anyway. I don't think today's big tech would do the same unless there is a clear, guaranteed way of monetizing it.
Dealing with N dimensional space of multiple OSes with multiple graphics APIs, multimedia engines, high DPI screens and complex text rendering is 90% painful software development. Somebody can do it but I don't think it will be open source, neither cheap.
Well that's the thing, Qt already has its smart pointer types which work with the QObject system - e.g. QPointer. You certainly wouldn't want to have a double layer of indirection, just like std::shared_ptr<QStuff> is an antipattern
> C++ is just not the greatest language for building GUI apps.
Compared to the other languages you listed, it demonstrably is. They've been around for over 10 years and aren't used much for the purpose. Maybe Rust and Go just aren't good (let alone great) for building GUI apps.
Compared to the other languages you listed, it demonstrably is. They've been around for over 10 years and aren't used much for the purpose. Maybe Rust and Go just aren't good (let alone great) for building GUI apps.
I'm currently building something in Go that should eventually work with Qt as one of the underlying drivers if that's possible.
I'm a bit afraid of the FFI costs but I will look into the nitty gritty later.
There is always possibilities for the electron/tauri/wails route if all else fails.
I'm a bit afraid of the FFI costs but I will look into the nitty gritty later.
There is always possibilities for the electron/tauri/wails route if all else fails.
If you want to use Rust, you can use the Slint toolkit. It is really similar to QML.
Having been involved as a C++/Qt developer for years, I also agree that C++ is a big hindrance for adoption of Qt.
I totally understand that nobody would want to learn C++, of all languages, in order to make their pet music collection manager, or whatever other app. I'd wager for 95% of apps, the fine control over memory and resources is just a premature optimization, and only brings friction by requiring to learn an arguably difficult to master language.
Go would be a great choice for general application development. Of course you might want to use C++ or Rust for a complex video editing package or something demanding like that... but to make the To-Do or Calculator app du jour, having to learn those languages is overkill. I guess that's also why there are so many Electron-based applications.
In general, having a garbage collector is a huge productivity boon, while not having to distribute a runtime interpreter (that's why I didn't mention Python) is also great.
I totally understand that nobody would want to learn C++, of all languages, in order to make their pet music collection manager, or whatever other app. I'd wager for 95% of apps, the fine control over memory and resources is just a premature optimization, and only brings friction by requiring to learn an arguably difficult to master language.
Go would be a great choice for general application development. Of course you might want to use C++ or Rust for a complex video editing package or something demanding like that... but to make the To-Do or Calculator app du jour, having to learn those languages is overkill. I guess that's also why there are so many Electron-based applications.
In general, having a garbage collector is a huge productivity boon, while not having to distribute a runtime interpreter (that's why I didn't mention Python) is also great.
The main downside of becoming a C++ dev is that all of other languages seem so inferior.
Fedora already has it built/released (on F39, at least)
edit: 12.0.0-0.2 appears to be -beta1 on closer look :D
edit: 12.0.0-0.2 appears to be -beta1 on closer look :D
Integrated Compiler Explorer looks pretty neat!
The Qt Creator bug tracker [1] is bursting at the seams but nobody seems to really care. 5+ years old, very reproducible, very annoying bugs are being ignored by the 100s.
Here's an idea: can we have a feature freeze for like 1 or 2 years and only solve bugs / tech debt? There's no new feature that you could put into Qt Creator that I'd prefer over bugfixes. None.
Eike, or others from the Qt team, if you're reading this, please give it a thought. You have a fantastic IDE and it's painful seeing it degrade so much. Thank you.
[1] https://bugreports.qt.io/projects/QTCREATORBUG/issues/