[deleted]
Developing a Beautiful and Performant Block Editor in Qt C++ and QML
21–30 of 66 posts
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#22I'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.
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#23(Author here)
Wow just noticed my blog post is on the front page! Will try to respond to all comments here soon.
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#24I've worked with QtWidgets and I have mixed feelings about the extensive (1) documentation about integrating C++ with QML and QtQuick. Here's a quick history lesson (as I understand it): - QtWidgets the original C++ QT graphics library. - Around 2008 or something, they introduced QML and QtQuick. This was basically declarative UI + javascript for logic. - QtWidgets is considered 'done' and all new features and dev is…
As someone who doesn't do too much GUI programming on Linux, I find QML quite useful, actually.
Small effects and simple state switches ("disable/hide this group of inputs when the user disables the 'advanced' checkbox") can be written in simple code. The advanced plumbing (custom control rendering, window management) is left to native code.
There's a delicate balance there that I can imagine will be difficult to maintain long-term, but many applications just need a handful of buttons and maybe a text field somewhere to do their job, and that's where QML shines.
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#25I'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 t…
(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.
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#26I'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 t…
(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 v…
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. :)
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#27Earlier quoted context omitted.
If you mean due to lack of C++ for doing GUIs, Google and Microsoft have also long left C++ to the dust, in what concerns GUI frameworks. Even Microsoft, for all its C++ use, has never produced anything better than MFC to this day, and only Windows team cares about XAML C++, others rather use React Native or Webview2 alongside C++. It is up to third parties to use frameworks like Qt.
I mean specific APIs and targets are required to be written in Swift (e.g. widgets) + iOS/macOS dev tooling is hostile to any attempt at bringing in your own preferred language stack. I wouldn't be surprised if Apple's "glasses" or other tiny devices make it even harder to stray from the "one true path".
How is it hostile?
Calling ObjC via your language of choice is like the easiest thing possible, solved multiple times over. Signing and notarizing outside of Xcode is also a solved problem.
IME people bitch about this but when push comes to shove just don’t want to do the required work, typically on flimsy grounds. It’s just not that hard.
The increase in Swift-only frameworks will eventually be a problem but it’s typically not a blocker right now.
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#28I've always lamented that QML and QtWidgets are separate rather than integrated. It would be awesome if there was a declarative way to specify much of the same information that you have to specify programmatically with QtWidgets (e.g., the cumbersome process of defining nested sizers), and then you could write code to handle the actual "business logic". But instead we have two totally separate UI frameworks where you…
It exists since 2018 aha https://www.kdab.com/declarative-widgets/
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#29Earlier quoted context omitted.
(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 v…
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 par…
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.
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#30Take my money!