4 ms·

> 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 yo

> 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".
righthand 3y ago
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.
- Longhanks 3y ago
  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.
- saidinesh5 3y ago
  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 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++.
  - righthand 3y ago
    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.
    - jenadine 3y ago
      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)
      - saidinesh5 3y ago
        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 https://forum.qt.io/topic/32701/qt-v8/4

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".

righthand 3y ago

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.

Longhanks 3y ago
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.
saidinesh5 3y ago
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 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++.
- righthand 3y ago
  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.
  - jenadine 3y ago
    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)
    - saidinesh5 3y ago
      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 https://forum.qt.io/topic/32701/qt-v8/4