I've worked with Qt about 15 years writing several applications both for work and for fun and overall I think it's a really powerful platform. Not without it's idiosyncrasies and quirks of course.

That being said I find that QML is complete trash. It's fine for simple UIs with minimal logic and prototypes but for anything beyond that you'll always need to implement the logic in C++ and this is where the pain enters the picture. A lot of effort will be spent maintaining the glue code that lets the two worlds comminicate. The tooling is poor and QMLs poor typing makes it hard to ever change anything from types to available methods..

Generally speaking QML has terrible shortcomings in its lack of good typing, debugging abilities, error reporting or general maintainability of the code. It's your typical "write once" platform where the cost comes later if/when you need to maintain and evolve the software later on.

▲

rubymamis 10 hours ago | parent [-]

(Author here)

I think the fact that Qt went with Javascript as the scripting language for QML wasn't a smart decision - especially resulting in poor type safety. That said, they have improved the situation by a lot with required properties, Q_ENUM where you can now share enums between C++ and QML etc etc.

I don't agree that QML is just for simple UIs, that's exactly what I tried to demystify - my block editor is a very complex project spanning around 20,000+ lines of code - and still managed to be the most performant block editor in all my tests.

Contrary to you, I love the separation between the logic being written in C++ and UI in QML I think it's absolutely a great combo - QML is such a great language to write UIs in and C++ is a performant compiled language that (I, personally) love writing logic in. Also, communicating between C++ and QML components is straightforward with Q_PROPERTYs and signal and slots.

▲

samiv 10 hours ago | parent | next [-]

Hello

Yes sure I've heard that Qt6 improves the integration and type safety but I haven't tried that yet myself.

Communicatingn with signals and slots and using Qt Property system is straightforward yes but even more straightforward is to when you don't have to use it. The real problem is when you change your properties or your underlying types or the methods, their names or signatures and NOTHING tells you which part of your QML code will be affected. You just have to.. kinda know. In practice you'll of course miss something and then it'll just blow up at runtime with some "bla bla is undefined" error.

That being said if you're comfortable to use it and find it works for you more power to you. I'll just stick to my widgets. :)

	▲	kalaksi 9 hours ago \| parent [-]
		I think the QML linter detects that but may require maintaining some extra files that tell which methods and properties are available in C++ classes. Not sure if they can be auto-generated if using C++ and more native tools since I've been using QML with Rust. Better type integration would be nice though.

▲

eek2121 6 hours ago | parent | prev [-]

IIRC, There are also bindings for other languages, at least I know Ruby used to have one that I played with.