I love how "professional" Qt code and API feels compared to GTK+ and how their team is not involved in any political drama. Always a joy to use their products.
> Bindings aren't ideal, I wish there was a native Linux gui toolkit with a "sane" language.
There's none, because all the linux GUI toolkit developers are "sane" enough to make the toolkit x-platform.
If you're looking for "something that runs on linux, and linux only, and nowhere else" you are not going to find anything the way you find "something that runs on windows, and windows only, and nowhere else".
There's a lot of overstated FUD about the moc. It's a preprocessor that expands a few macro strings into relatively simple boilerplate C++. Yes, it's a separate little preprocessor binary instead of using C++'s built-in macro system, but the concept itself is not foreign to C++.
The macro incantations aren't massively complicated and mostly are simple labels placed in header files; body code rarely uses anything moc-related these days.
Compared to the crazy stuff Microsoft has done over the years within and on top of C++ on their platform, Qt's moc is barely a footnote.
I respect not liking it, and I totally get the appeal of doing the same thing with tools built directly into the language (which to this day aren't fully comparable, and are mostly recent - check into the verdigris project for a solid and interesting take on attempting this), but it's a reasonably straight-forward approach to the problems it solves.
> Yes, it's a separate little preprocessor binary instead of using C++'s built-in macro system, but the concept itself is not foreign to C++.
It does have it's drawbacks. The MOC heavily penalizes build times, and build caching tools like ccache don't work out of the box with it. So not only does the MOC worsens builds, it also prevents basic optimizations from mitigating it.
> Compared to the crazy stuff Microsoft has done over the years (...)
Microsoft did a fantastic job with it's GUI frameworks. WPF is a stellar example of getting most things right. It's astounding how views are so trivial with WPF. XAML voodoo has it's critics but no one praising Qt would ever dare point a finger at XAML.
> It does have it's drawbacks. The MOC heavily penalizes build times, and build caching tools like ccache don't work out of the box with it. So not only does the MOC worsens builds, it also prevents basic optimizations from mitigating it.
You have to compare those drawbacks directly to the alternatives, though. I don't have numbers to cite, but I think the attempts at replacing the moc with newer C++ lang features also usually didn't exactly hit the compiler fast paths.
Yes, perhaps optimizing the compilers would be nicer.
> You have to compare those drawbacks to the alternatives, though. I don't have numbers to cite, but I think the attempts at replacing the moc with newer C++ lang features also usually didn't exactly hit the compiler fast paths.
Maybe so, but this is not what my comment is about. What I'm saying is that MS has made much more invasive changes to C++ as a language than Qt has in its platforms or frameworks, e.g. compiler-backed extended and different behavior. Or look at C++/CX (since phased out, thankfully).
There's a lot of "If you're using Qt you're not using C++!!1" FUD to confuse newbies, while it's much easier to inadvertently write non-portable C++ with many other frameworks. Yes, it's a whatboutism (which I hope to have compensated for with many other detailed comments in the thread), but this double standard tends to irk me.
> You have to compare those drawbacks directly to the alternatives, though.
It's ok to claim that Qt's MOC optimizes for developer experience,and all other tradeoffs are acceptable.
> I don't have numbers to cite, but I think the attempts at replacing the moc with newer C++ lang features also usually didn't exactly hit the compiler fast paths.
This doesn't really matter. It's not just the MOC. Using Qt UI form files forces UIC into the picture, which also fails to be cached.
> Yes, perhaps optimizing the compilers would be nicer.
The compiler is not the problem. Obviously. WPF also uses code generators and it's not plagued with long build times.
> Maybe so, but this is not what my comment is about. What I'm saying is that MS has made much more invasive changes to C++ as a language than Qt has in its platforms or frameworks, e.g. compiler-backed extended and different behavior. Or look at C++/CX (since phased out, thankfully).
This reads like whataboutism, and fails to address Qt's problems.
> There's a lot of "If you're using Qt you're not using C++!!1" FUD to confuse newbies
I never saw that once, not do I understand why that is relevant.
moc is the part of C++ the standards folks didn't see a need to integrate, but it should have always been there. Since all it does is take syntactic sugar and output more C++, it's clearly C++.
of course, C++ eventually gained the ability to implement moc natively using a more general solution.
to me, moc and the Qt base classes sort of round out C++ to me in a way that is better than the alternatives. I can imagine an entire world of application development based on Qt C++ base, and in fact I've written a few network servers this way. Simply having event loops with message passing built-in makes programming that much more enjoyable for me.
GTK has bindings to modern languages. The gtk-rs project is actively working on Rust bindings. I'm personally working with some others on Kotlin Native bindings and I know a new JVM effort is in progress using the new JVM FFI capabilities.
Gtk is C, but it's introspected in a way that it generates really good bindings for other languages. gtkmm and gtk-rs are really good.
Qt is C++ through and through. Even more so because of its MOC. It's really hard to port to other languages.
If we wanted a standard toolkit for Linux, it'd have to be written C to be compatible with most FFIs. The problem with Gtk is it's in coalition with Gnome, and its developers shun anything not fitting that scope.
Ho-humm, I'd argue that specific point. The meta-object system adds introspection and reflection, and helps it get e.g. fantastic Python bindings. Various other bindings are also basically built around wrapping QObject+QMetaObject.
Yes, binding Qt is anyway harder than GTK's C API. But not because of the MOC.
Having never written using any of these technologies, I was wondering how ergonomic GTK would be in Rust. Isn't GTK very object-oriented in its design?
I’d argue that Qt API is pre-C++98, ie. pre std template library. Qt uses its own classes (vector, string, etc) instead of std template library. Even the MOC can be eliminated with the STL. Its an ancient API which is separate from modern post C++11. They’ve tried adding some STL and C++11 concepts, but they have millions of lines of legacy code to support, so its just more layers and bloat.
You're not completely wrong, but I think this overstating things by a lot. I'll grant you the containers for example, but you can generally use STL algorithms with them. And plenty of old ways of doing things have left modern Qt-based codebases and moved to more modern ways of doing things, including a fair amount of moc macro usage (and yes, you can remove the moc these days, but it has different perf characteristics - cf. the verdigris project).
It is still C++ and in many aspects, much better than the current trends on the standard library design.
Also, alongside VCL/Firemonkey, miles ahead of any C++ UI framework produced by Microsoft, WinDev just has no taste in doing GUI tooling for C++ developers.
I kind of disagree. GTK+ gets a lot of (sometimes deserved) flak for their API choices but Qt isn't all that different. They have plenty of weird legacy APIs, design choices, and restrictions on their API design so they can keep selling their paid products.
With GTK+ you get a Gitlab issue where everyone from GTK+ developers to /g/ users spout their opinions and then eventually the team and the developers take a decision that's probably going against at least half the comments in the thread.
With Qt you get "this is the API, live with it". I'd describe its API design method close(r) to the Windows API than any open source API I know of.
Sure, it creates a lot less drama, but at the cost of openness.
I'm not a fan of any Linux UI design toolkit, but I found GNOME Builder to be much more intuitive and working better out of the box than Qt Creator. GNOME's UI language may be... a choice, but Qt applications often feel like toy UIs or those fake operating systems you find in games without some pretty deliberate planning (and styling). With libadwaita being brought into GTK+ I think neither looks any good out of the box now, but the tooling for GNOME seems a lot better at least.
In terms of API and tooling support, I don't think any open projects come close to what Microsoft did with Visual Studio and C# back in 2005.
> With Qt you get "this is the API, live with it".
This is true often, but not always. Quite a bit of Qt APIs get created collaboratively on gerrit; I've had API changed based on my input. It's also possible to contribute APIs; I've done that, too. Some bigger new modules or API surface area is also moved through Qt Labs first before becoming part of the product, making for a longer feedback period. We've also had Qt folks actively attending events like Akademy to demo new WIP APIs and gather feedback and feature requests and engage in PoC ports of real software. There's also venues like the annual Qt Contributor Summit for larger discussions.
You're right that this open approach is not the only channel for APIs into Qt, and in hybrid communities like his there's always some tension, and of course having to be a little "in the know" or engaged in the community means there's perhaps a higher barrier to entry in some ways. I respect not liking that and preferring if there's only a community-based channel.
It's also worth pointing out that for the most part, Qt has a fairly healthy approach to low/mid/high level customizability and extensibility to its API. It has internalized this as one of the reasons for its success, even if it sadly fell a bit by the wayside during the early Qt Quick years. That means that "this is the API, live with it" is not really a straitjacket - you get to override, supplant, extend a lot.
It's ugly (to some/many) and unthemable which is a huge problem when aesthetics are subjective and highly variable. The unthemability is intentional and intended to be permanent, which won't just apply to GNOME but all Gtk+ programs. So, an authoritarian disaster and big step backwards.
I dislike many things about GTK, although I have not tried to program using it so I cannot comment about the API (I have not programmed using Qt either). Qt is not that good either, in my opinion. I prefer Xaw, and I have done some programming using Xaw. (What I want is a compatibility library with the same API as GTK and Qt but does just calls other widget sets instead)
> Qt Creator is a cross-platform, complete integrated development environment (IDE) for application developers to create applications for multiple desktop, embedded, and mobile device platforms, such as Android and iOS. It is available for Linux, macOS and Windows operating systems... In addition, you can use the experimental WebAssembly plugin to build applications in web format and run them in web browsers.
flutter + dart might be an alternative to Qt these days for cross platform GUIs, which is what I'm learning these days, in addition to desktop it does mobile platforms as well.
What OP means is that everything there suggests the Riva folks are releasing their tech for Flutter as an add-on, while your original comment suggests the Flutter project is adopting/integrating this tech inside Flutter. I was also confused.
Note that this is about Qt Creator, and not Qt. Though it is created by Qt company primarily to work with Qt, it is a very capable C/C++ IDE on its own right, even if you don't use Qt at all.
Qt is a C++ toolkit, and Qt-based projects are either C++, or use the QML markup language, or both.
Projects that use Qt for the GUI or use other Qt modules often also use other C/C++ libraries (for example, in-house stuff) and they're often hacked on together.
Therefore the free IDE you can get for Qt also happens to be a very good C/C++ IDE/editor.
Qt uses CMake as its native built system - arguably CMake was popularized in general when KDE adopted it, a large FOSS user of Qt. CMake is not Qt-specific, and many other C/C++ libs use or integrate well with CMake. Therefore Qt's free IDE is also very good at general CMake support.
Qt is often used for embedded or heavier IoT projects, therefore the IDE has useful features for deployment and remote debugging that also work for other stuff. And so on.
The Qt Company doesn't really push/advertise Qt Creator much as an independent product, but the utility is really not bad.
I'm guessing that the part that would make it make sense for me is that the Qt Creator is made by the team that makes Qt or something in that ecosystem that's a label they give themselves. For instance I wouldn't call an IDE I made, Swing Creator if it was made with Java Swing but I had no other association.
Make no mistake, the main reason Qt Creator exists is to enable and promote Qt-based development and tick a box when selling to customers. They don't sell Creator individually (it's free), so they don't really make money from it outside of Qt sales.
Qt competes for major business in markets like automotive or general embedded, where vendor frameworks are from the "one-stop solution for Windows" generation that come with IDEs aimed at specialists that get trained to use them, e.g. because they have a mechatronics/Simulink/etc background more than a programming one. Or because they're designers and used to Photoshop/Figma and you need something you can import into. These are often horribly old and crufty Eclipse derivatives or even OG Win32 MFC apps.
Examples would be boutique solutions you've never ever heard of but probably used or seen in a car, e.g. the Kanzi toolkit, or STM's TouchGFX for microcontrollers.
So Qt decided to make one too to round out the value prop.
It's just that Qt (a) grew up originally as a desktop UI toolkit for PCs (so using it for a desktop app works out) and (b) is on a much cleaner, much more general-purpose tech stack, so it happens to actually be fairly good and reasonably general-purpose. Partly also because the Qt folks who wrote it simply used other desktop IDEs or classic hacker's editors before and decided to make a IDE they would themselves like to use.
That said, The Qt Company has more recently done some acquisitions that actually do go more into the direction of branching out into development tools. They acquired Froglogic, makers of Squish (a GUI unit testing framework in wide use) and also a Coverity-like code scanner. So who knows, maybe they'll reposition Creator a bit.
If you don't mind my indulgence, does Qt Creator have any features specific to developing with Qt? Along the lines of Xcode being able to edit resources or graphically connect components, etc? Even a specialized search that's better at finding Qt things. That would take away all ambiguity.
Yes. Qt as a framework comes with a built-in declarative markup language called QML (a superset of ECMAScript). Full IDE support for QML including debugging/profiling and also a visual design/editing mode are unique to Qt Creator.
You can use Qt Creator while ignoring or perhaps even without realizing this is there (since also many, though increasingly fewer, Qt apps are written in pure C++ without any QML use), but if you do use Qt, it's of course a large potential value add.
I use VSCode to develop Qt apps; I tried qt creator but like Eclipse and NetBeans, I found them to be "less general".
The one tool I truly love is Qt Designer, which is a GUI designer that outputs declarative config for the GUI, but also makes it easy to plug in custom classes for special widgets. It's the most rational and practical GUI designer I've used.
Whoa! What a blast from the past! I remember using Qt in ca. 2002 when interning for a robotics institute. My advisor wasn't available for the first week or two so I had free reign to do what I want. I ended up using Qt to create a robot simulator which uses laser eyes to navigate through a simple maze of obstacles.
It was a super-simple algorithm (I'm hardly the scientist, more like a pragmatic developer), but it seemed as if it were doing complex things and Qt helped make it look relatively cool even with my basic coding abilities.
Finally, first time I can contribute a "I remember a couple of decades ago when I was using tool X". I'm a web dev now and I have a more laid back stance regarding new tech, so I never write "Oh, I wrote a SPA-transpiled prototype with RustJs 0.0.4rc" or whatever (been burned too many times; e.g. bower, grunt, gulp, AngularJS 1, etc).
59 comments
[ 3.2 ms ] story [ 137 ms ] threadNot a fan of comments that praise product A with some sort of vaguely axe-grinding reference to product B.
Bindings aren't ideal, I wish there was a native Linux gui toolkit with a "sane" language.
One of them is.
> Bindings aren't ideal, I wish there was a native Linux gui toolkit with a "sane" language.
There's none, because all the linux GUI toolkit developers are "sane" enough to make the toolkit x-platform.
If you're looking for "something that runs on linux, and linux only, and nowhere else" you are not going to find anything the way you find "something that runs on windows, and windows only, and nowhere else".
None of them I'd say. I'd argue moc is not C++
The macro incantations aren't massively complicated and mostly are simple labels placed in header files; body code rarely uses anything moc-related these days.
Compared to the crazy stuff Microsoft has done over the years within and on top of C++ on their platform, Qt's moc is barely a footnote.
I respect not liking it, and I totally get the appeal of doing the same thing with tools built directly into the language (which to this day aren't fully comparable, and are mostly recent - check into the verdigris project for a solid and interesting take on attempting this), but it's a reasonably straight-forward approach to the problems it solves.
It does have it's drawbacks. The MOC heavily penalizes build times, and build caching tools like ccache don't work out of the box with it. So not only does the MOC worsens builds, it also prevents basic optimizations from mitigating it.
> Compared to the crazy stuff Microsoft has done over the years (...)
Microsoft did a fantastic job with it's GUI frameworks. WPF is a stellar example of getting most things right. It's astounding how views are so trivial with WPF. XAML voodoo has it's critics but no one praising Qt would ever dare point a finger at XAML.
You have to compare those drawbacks directly to the alternatives, though. I don't have numbers to cite, but I think the attempts at replacing the moc with newer C++ lang features also usually didn't exactly hit the compiler fast paths.
Yes, perhaps optimizing the compilers would be nicer.
> You have to compare those drawbacks to the alternatives, though. I don't have numbers to cite, but I think the attempts at replacing the moc with newer C++ lang features also usually didn't exactly hit the compiler fast paths.
Maybe so, but this is not what my comment is about. What I'm saying is that MS has made much more invasive changes to C++ as a language than Qt has in its platforms or frameworks, e.g. compiler-backed extended and different behavior. Or look at C++/CX (since phased out, thankfully).
There's a lot of "If you're using Qt you're not using C++!!1" FUD to confuse newbies, while it's much easier to inadvertently write non-portable C++ with many other frameworks. Yes, it's a whatboutism (which I hope to have compensated for with many other detailed comments in the thread), but this double standard tends to irk me.
It's ok to claim that Qt's MOC optimizes for developer experience,and all other tradeoffs are acceptable.
> I don't have numbers to cite, but I think the attempts at replacing the moc with newer C++ lang features also usually didn't exactly hit the compiler fast paths.
This doesn't really matter. It's not just the MOC. Using Qt UI form files forces UIC into the picture, which also fails to be cached.
> Yes, perhaps optimizing the compilers would be nicer.
The compiler is not the problem. Obviously. WPF also uses code generators and it's not plagued with long build times.
> Maybe so, but this is not what my comment is about. What I'm saying is that MS has made much more invasive changes to C++ as a language than Qt has in its platforms or frameworks, e.g. compiler-backed extended and different behavior. Or look at C++/CX (since phased out, thankfully).
This reads like whataboutism, and fails to address Qt's problems.
> There's a lot of "If you're using Qt you're not using C++!!1" FUD to confuse newbies
I never saw that once, not do I understand why that is relevant.
of course, C++ eventually gained the ability to implement moc natively using a more general solution.
to me, moc and the Qt base classes sort of round out C++ to me in a way that is better than the alternatives. I can imagine an entire world of application development based on Qt C++ base, and in fact I've written a few network servers this way. Simply having event loops with message passing built-in makes programming that much more enjoyable for me.
Qt is C++ through and through. Even more so because of its MOC. It's really hard to port to other languages.
If we wanted a standard toolkit for Linux, it'd have to be written C to be compatible with most FFIs. The problem with Gtk is it's in coalition with Gnome, and its developers shun anything not fitting that scope.
Ho-humm, I'd argue that specific point. The meta-object system adds introspection and reflection, and helps it get e.g. fantastic Python bindings. Various other bindings are also basically built around wrapping QObject+QMetaObject.
Yes, binding Qt is anyway harder than GTK's C API. But not because of the MOC.
I’d argue that Qt API is pre-C++98, ie. pre std template library. Qt uses its own classes (vector, string, etc) instead of std template library. Even the MOC can be eliminated with the STL. Its an ancient API which is separate from modern post C++11. They’ve tried adding some STL and C++11 concepts, but they have millions of lines of legacy code to support, so its just more layers and bloat.
The community around Qt is pretty active at adopting modern C++, e.g. imho https://github.com/danvratil/qcoro is leading work.
I'm glad that folks clamor for keeping things fresh, but every 30 year old project is going to span a few minor revolutions along the way.
Also, alongside VCL/Firemonkey, miles ahead of any C++ UI framework produced by Microsoft, WinDev just has no taste in doing GUI tooling for C++ developers.
With GTK+ you get a Gitlab issue where everyone from GTK+ developers to /g/ users spout their opinions and then eventually the team and the developers take a decision that's probably going against at least half the comments in the thread.
With Qt you get "this is the API, live with it". I'd describe its API design method close(r) to the Windows API than any open source API I know of.
Sure, it creates a lot less drama, but at the cost of openness.
I'm not a fan of any Linux UI design toolkit, but I found GNOME Builder to be much more intuitive and working better out of the box than Qt Creator. GNOME's UI language may be... a choice, but Qt applications often feel like toy UIs or those fake operating systems you find in games without some pretty deliberate planning (and styling). With libadwaita being brought into GTK+ I think neither looks any good out of the box now, but the tooling for GNOME seems a lot better at least.
In terms of API and tooling support, I don't think any open projects come close to what Microsoft did with Visual Studio and C# back in 2005.
This is true often, but not always. Quite a bit of Qt APIs get created collaboratively on gerrit; I've had API changed based on my input. It's also possible to contribute APIs; I've done that, too. Some bigger new modules or API surface area is also moved through Qt Labs first before becoming part of the product, making for a longer feedback period. We've also had Qt folks actively attending events like Akademy to demo new WIP APIs and gather feedback and feature requests and engage in PoC ports of real software. There's also venues like the annual Qt Contributor Summit for larger discussions.
You're right that this open approach is not the only channel for APIs into Qt, and in hybrid communities like his there's always some tension, and of course having to be a little "in the know" or engaged in the community means there's perhaps a higher barrier to entry in some ways. I respect not liking that and preferring if there's only a community-based channel.
It's also worth pointing out that for the most part, Qt has a fairly healthy approach to low/mid/high level customizability and extensibility to its API. It has internalized this as one of the reasons for its success, even if it sadly fell a bit by the wayside during the early Qt Quick years. That means that "this is the API, live with it" is not really a straitjacket - you get to override, supplant, extend a lot.
Yeah, this is the part that hurts. So much work done on the backend and so many great apps, then to lock everything into that...
From https://doc.qt.io/qtcreator/index.html
https://twitter.com/guidorosso/status/1639080101186011136
https://twitter.com/guidorosso/status/1595187838454140928
This tweet in particular:
https://twitter.com/guidorosso/status/1639080107301306369
/sigh
Is a better language than Java.
Qt is a C++ toolkit, and Qt-based projects are either C++, or use the QML markup language, or both.
Projects that use Qt for the GUI or use other Qt modules often also use other C/C++ libraries (for example, in-house stuff) and they're often hacked on together.
Therefore the free IDE you can get for Qt also happens to be a very good C/C++ IDE/editor.
Qt uses CMake as its native built system - arguably CMake was popularized in general when KDE adopted it, a large FOSS user of Qt. CMake is not Qt-specific, and many other C/C++ libs use or integrate well with CMake. Therefore Qt's free IDE is also very good at general CMake support.
Qt is often used for embedded or heavier IoT projects, therefore the IDE has useful features for deployment and remote debugging that also work for other stuff. And so on.
The Qt Company doesn't really push/advertise Qt Creator much as an independent product, but the utility is really not bad.
Qt competes for major business in markets like automotive or general embedded, where vendor frameworks are from the "one-stop solution for Windows" generation that come with IDEs aimed at specialists that get trained to use them, e.g. because they have a mechatronics/Simulink/etc background more than a programming one. Or because they're designers and used to Photoshop/Figma and you need something you can import into. These are often horribly old and crufty Eclipse derivatives or even OG Win32 MFC apps.
Examples would be boutique solutions you've never ever heard of but probably used or seen in a car, e.g. the Kanzi toolkit, or STM's TouchGFX for microcontrollers.
So Qt decided to make one too to round out the value prop.
It's just that Qt (a) grew up originally as a desktop UI toolkit for PCs (so using it for a desktop app works out) and (b) is on a much cleaner, much more general-purpose tech stack, so it happens to actually be fairly good and reasonably general-purpose. Partly also because the Qt folks who wrote it simply used other desktop IDEs or classic hacker's editors before and decided to make a IDE they would themselves like to use.
That said, The Qt Company has more recently done some acquisitions that actually do go more into the direction of branching out into development tools. They acquired Froglogic, makers of Squish (a GUI unit testing framework in wide use) and also a Coverity-like code scanner. So who knows, maybe they'll reposition Creator a bit.
You can use Qt Creator while ignoring or perhaps even without realizing this is there (since also many, though increasingly fewer, Qt apps are written in pure C++ without any QML use), but if you do use Qt, it's of course a large potential value add.
The one tool I truly love is Qt Designer, which is a GUI designer that outputs declarative config for the GUI, but also makes it easy to plug in custom classes for special widgets. It's the most rational and practical GUI designer I've used.
It was a super-simple algorithm (I'm hardly the scientist, more like a pragmatic developer), but it seemed as if it were doing complex things and Qt helped make it look relatively cool even with my basic coding abilities.
Finally, first time I can contribute a "I remember a couple of decades ago when I was using tool X". I'm a web dev now and I have a more laid back stance regarding new tech, so I never write "Oh, I wrote a SPA-transpiled prototype with RustJs 0.0.4rc" or whatever (been burned too many times; e.g. bower, grunt, gulp, AngularJS 1, etc).