4 ms·

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

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.

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.