10 ms·

Qt Creator 12 Released

103 points by jandeboevrie 3y ago

righthand 3y ago
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.
- billfruit 3y ago
  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?
  - righthand 3y ago
    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.
  - saidinesh5 3y ago
    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
    - jcelerier 3y ago
      https://ossia.io https://ossia.io uses verdigris pretty much exclusively. Worse syntax but lots of advantages compared to moc.
      - jenadine 3y ago
        What advantages?
        jcelerier 3y ago
        - 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
  - pjmlp 3y ago
    Not until reflection comes to be. Maybe with concepts + if constexpr + traits, if one is willing to open the druids metaprogramming book.
  - vintagedave 3y ago
    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/n1384.pdf 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.
    - zerr 3y ago
      wxWidgets, FLTK and gtkmm use only pure C++ (and some preprocessor macros).
      - zik 3y ago
        Sure, but the PME approach Qt uses makes constructing complex UIs quite a lot easier.
- LorenDB 3y ago
  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.
  - righthand 3y ago
    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.
    - saidinesh5 3y ago
      > 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.
      - Palomides 3y ago
        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
        saidinesh5 3y ago
        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".
- jwells89 3y ago
  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”.
  - saidinesh5 3y ago
    Officially, There were QtQuickControls: https://doc.qt.io/qt-6/qtquickcontrols-index.html 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).
    - sho_hn 3y ago
      Qt Quick Controls still exist and are supported and actively developed - in the 2.x version range, since 2016.
      - saidinesh5 3y ago
        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.
  - righthand 3y ago
    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.
- spacechild1 3y ago
  This article is about the Qt Creator IDE, not about the Qt Framework, though.
- rewmie 3y ago
  > (...) 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.
hermitcrab 3y ago
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?).
rubymamis 3y ago
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/ https://www.get-plume.com/. I can't recommend Qt more!
- saidinesh5 3y ago
  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?
  - rubymamis 3y ago
    Nothing fancy, just the built-in ones. The rest I customize myself (very easy to do).
- spacechild1 3y ago
  This is about the Qt Creator IDE, not about the Qt framework!
bravetraveler 3y ago
Fedora already has it built/released (on F39, at least) edit: 12.0.0-0.2 appears to be -beta1 on closer look :D
api 3y ago
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.
- jcelerier 3y ago
  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.
  - api 3y ago
    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.
    - jcelerier 3y ago
      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
    - okanat 3y ago
      > 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.
pjmlp 3y ago
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.
- dist-epoch 3y ago
  You misspelled Electron. I can't remember the last time I saw a new Qt app.
  - speedgoose 3y ago
    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.
    - pjmlp 3y ago
      Eletron, when one cares more about themselves than their users. (TM)
      - alostpuppy 3y ago
        That should be a shirt
    - sho_hn 3y ago
      Ditto Mercedes.
    - jeroenhd 3y ago
      Tesla using Qt for GUI while SpaceX uses Electron shows how crazy modern UI development has become.
      - inferiorhuman 3y ago
        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.
rsp1984 3y ago
Long time Qt / Creator user here (15+ years). Qt Creator used to be the best C++ IDE by a mile and it's still pretty competitive (yes, you can use it without any Qt whatsoever!), however these days I am very unexcited about new releases of it. It looks like the Qt team prioritizes ever more features (who's asking for these!?) and bloat over fixing even the most basic of bugs. It's really baffling. 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/ https://bugreports.qt.io/projects/QTCREATORBUG/issues/
- nly 3y ago
  They should just give up and add the features that are compelling to Code via extensions.
- octorian 3y ago
  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.
- persnickety 3y ago
  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.
  - halJordan 3y ago
    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.
5643777909 3y ago
[dead]
jclay 3y ago
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.
snvzz 3y ago
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.
mardifoufs 3y ago
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.
- jcelerier 3y ago
  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
- pjmlp 3y ago
  Maybe because Qt Design Studio is what matters nowadays.
spacechild1 3y ago
Integrated Compiler Explorer looks pretty neat!

103 points by jandeboevrie 3y ago

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.

billfruit 3y ago
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?
- righthand 3y ago
  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.
- saidinesh5 3y ago
  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
  - jcelerier 3y ago
    https://ossia.io https://ossia.io uses verdigris pretty much exclusively. Worse syntax but lots of advantages compared to moc.
    - jenadine 3y ago
      What advantages?
      - jcelerier 3y ago
        - 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
- pjmlp 3y ago
  Not until reflection comes to be. Maybe with concepts + if constexpr + traits, if one is willing to open the druids metaprogramming book.
- vintagedave 3y ago
  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/n1384.pdf 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.
  - zerr 3y ago
    wxWidgets, FLTK and gtkmm use only pure C++ (and some preprocessor macros).
    - zik 3y ago
      Sure, but the PME approach Qt uses makes constructing complex UIs quite a lot easier.
LorenDB 3y ago
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.
- righthand 3y ago
  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.
  - saidinesh5 3y ago
    > 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.
    - Palomides 3y ago
      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
      - saidinesh5 3y ago
        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".
jwells89 3y ago
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”.
- saidinesh5 3y ago
  Officially, There were QtQuickControls: https://doc.qt.io/qt-6/qtquickcontrols-index.html 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).
  - sho_hn 3y ago
    Qt Quick Controls still exist and are supported and actively developed - in the 2.x version range, since 2016.
    - saidinesh5 3y ago
      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.
- righthand 3y ago
  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.
spacechild1 3y ago
This article is about the Qt Creator IDE, not about the Qt Framework, though.
rewmie 3y ago
> (...) 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.

hermitcrab 3y ago

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?).

rubymamis 3y ago

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/ https://www.get-plume.com/. I can't recommend Qt more!

saidinesh5 3y ago
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?
- rubymamis 3y ago
  Nothing fancy, just the built-in ones. The rest I customize myself (very easy to do).
spacechild1 3y ago
This is about the Qt Creator IDE, not about the Qt framework!

bravetraveler 3y ago

Fedora already has it built/released (on F39, at least) edit: 12.0.0-0.2 appears to be -beta1 on closer look :D

api 3y ago

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.

jcelerier 3y ago
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.
- api 3y ago
  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.
  - jcelerier 3y ago
    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
  - okanat 3y ago
    > 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.

pjmlp 3y ago

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.

dist-epoch 3y ago
You misspelled Electron. I can't remember the last time I saw a new Qt app.
- speedgoose 3y ago
  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.
  - pjmlp 3y ago
    Eletron, when one cares more about themselves than their users. (TM)
    - alostpuppy 3y ago
      That should be a shirt
  - sho_hn 3y ago
    Ditto Mercedes.
  - jeroenhd 3y ago
    Tesla using Qt for GUI while SpaceX uses Electron shows how crazy modern UI development has become.
    - inferiorhuman 3y ago
      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.

rsp1984 3y ago

Long time Qt / Creator user here (15+ years). Qt Creator used to be the best C++ IDE by a mile and it's still pretty competitive (yes, you can use it without any Qt whatsoever!), however these days I am very unexcited about new releases of it. It looks like the Qt team prioritizes ever more features (who's asking for these!?) and bloat over fixing even the most basic of bugs. It's really baffling. 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/ https://bugreports.qt.io/projects/QTCREATORBUG/issues/

nly 3y ago
They should just give up and add the features that are compelling to Code via extensions.
octorian 3y ago
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.
persnickety 3y ago
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.
- halJordan 3y ago
  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.

5643777909 3y ago

[dead]

jclay 3y ago

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.

snvzz 3y ago

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.

mardifoufs 3y ago

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.

jcelerier 3y ago
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
pjmlp 3y ago
Maybe because Qt Design Studio is what matters nowadays.

spacechild1 3y ago

Integrated Compiler Explorer looks pretty neat!