[ravenstine]

It really confuses me how anyone would have anything good to say about QML. Qt taking that direction just seems like a panicked decision to try and compete with Electron when they should really be doing the exact opposite.

My experience with QML/Quick is that while you get a little JavaScript runtime and a slightly less obtuse way of defining "widgets" and application layouts than the original Qt "forms", there are some clear drawbacks that make it a near non-starter for anything I've thought about using it for.

Right out of the box, you have to use QML, which is a weird hybrid of language/markup paradigms, and it's a proprietary language. What designer knows QML? Probably f$#%& zero. Electron wins right out of the gate because what designers don't know at least something about HTML and CSS? Sure, if QML was that groundbreaking then maybe people would learn it, but it's owned by a company and it brings nothing new to the table that HTML and CSS can't do better.

The solution to most things in Quick is to write JavaScript. I've been a JavaScript engineer for most of my career, but when you're writing a Qt application then the obvious place to do anything useful or complex is in the host language of C++ or Python. So what if you want to tie behavior between your Quick widget and a C++ library you either wrote yourself or have imported from a vendor? Well, you can kinda sorta do that, but it's hard to explain here; let's just say that tying a widget to C++ code is extremely clumsy, and good luck calling a function on a Quick widget class because you just can't simply do that.

For instance, Qt provides a WebView widget, which was exactly what I needed recently. Uh oh, the decided to make it a Quick widget only, rather that do the obvious thing of exposing it as a C++ class and providing a Quick widget that wraps around it. Why did they do this? I guess it's because in the long term they think that they'll move away from classic widgets entirely. In any case, I wanted to call the `runJavaScript` method on the widget class without having to jump through hoops in QML. The only way to make that happen was to hack the build process to expose private methods.

But I realized that, at that point, there was no longer any point in using Quick if I was going to have to use some neat tricks in C++.

So in just a day, I wrote a classic widget that implements the same WebView used in the Quick version, just without any of the QML crap.

https://github.com/Ravenstine/qt-web-view-widget

And yeah, Qt does provide some form of a WebView in as a classic widget but, guess what, it involves bundling a browser runtime rather than using the browser engine of the host OS. Makes sense if you need more of the browser APIs exposed, but if all you want to do is show some simple things on a webpage and call JS from C++, then going through the effort of compiling Qt with support for that browser engine is overkill.

Overall, I don't mind most things about Qt. Despite how overcomplicated some of it is, it does what I want, which is to allow me to write native desktop apps without needing to invest much of my knowledge in OS-specifics. I like that I can use their Bluetooth library and, besides some quirks with how macOS handles device identifiers, I can compile it on other platforms and it will work for the most part.

I wish they'd abandon QML/Quick and just focus on making the experience of writing completely native apps better. I also see no reason why the solution to mobile development can't simply be different sets of classic widgets that are mobile-specific.

[dkersten]

I built an editor for creating visualisations for an LED grid hardware project. The editor was built in QML (but with lots of C++). It had a grid visualising the LEDs as squares (I believe that was drawn, iirc, not using QML rectangles) And a timeline track editor where you could place effects (four tracks), drag them around, drag their length, select effects to edit their properties in a properties label etc.

Whole thing was built in about 3 days and I would say it was a huge success (visualisation crested with it was used at a gig of about 1.2k attendees and creating the editor meant being able to iterate quickly to create a visualisation the musicians were happy with, LEDs were attached to clothing). I certainly enjoyed the experience.

Doing it in Qt meant that I could write C++ code to “run” the visualisation, but with a different display implementation (editor version drew to the editor, hardware version outputted to the LED hardware, but the track runtime was the same code). QML made building the UI easy.

Nowadays I mainly do React-based web UI’s, but I still much prefer QML to html/react/css. I especially miss QML’d anchors for layouts.

[ravenstine]

Thanks for providing an opposite opinion! I don't suppose there's video, photos, or code of your project? No worries if you don't. Just sounds really cool!

[HDevo]

I'm not the parent, but I did something similar. It's an editor for fractal flames where the UI is done in QML and rendering and generation is done in C++ and OpenGL. https://github.com/chaoskit/chaoskit

I liked that QML allowed me to iterate quickly on the UI. It was really quick to just compose a bunch of components together and have something working. I also enjoyed the integration with the C++ side. Overall I found QML pretty solid. If I'd build a desktop app again, I'd definitely consider it.

[dkersten]

I have the code on GitHub but I haven’t built the code in 4 years so don’t have a screenshot. Like I said, the code was written in about 3 days and QML allowed me to iterate quickly, but the resulting code quality isn’t great (since it was a once off project, built and used in the same week and then never used again, I didn’t clean it up or anything).

The editor simulated the LED strip using the same code to generate the effects as the on device version (which just ran without the UI and a different “driver” class implementation). It ran on a Raspberry Pi so the device wasn’t a microcontroller or anything, which made it easy to run the C++ code. In theory I could have made it run in a microcontroller but it wasn’t necessary for the project and time was limited.

Anyway, the code is here: https://github.com/danielytics/ledstudio

And the QML specifically is here: https://github.com/danielytics/ledstudio/blob/master/main.qm...

If I were to clean it up, I would at least split the different labels into their own QML files but hey, shortcuts were taken over those few days :)

Visually, it didn’t look all that great, but I’m not a UI person either and it was rushed. Functionally it could have been improved too, but it did what it was supposed to and it worked well. It allowed us to create various LED effect sequences quickly and play them back later.

I personally quite like QML. It’s not perfect, by any means, but I like using it more than React (which is what I’ve been using on projects since due to needing to be web based).

[jcelerier]

Qt 4.7 (in 2010) is older than electron (2013), how could it be a panicked decision ?

Also, there's nothing wrong with using Qt Quick from C++, or using QML without Qt Quick at all. what matters is your project, not what whatever best practices say.

[joezydeco]

Qt Quick/Declaritive/QML was Nokia's reaction to iOS and Android. They wanted an easy transition for JavaScript developers.

It's finally matured into a usable system now that application processor horsepower has caught up in the embedded field. It only took 12 years.

[hallarempt]

"Right out of the box, you have to use QML"

No, you don't.

[ravenstine]

Technically, you don't have to. But is that not what you are really supposed to be doing? Who wants to write a Quick app without QML? That would be incredibly painful, I think.

And unless I'm mistaken, if you're doing anything with JavaScript, that's all defined in QML. I don't think there's a way around that, unless I'm mistaken. And often times you need JS to achieve certain things in the separate memory space where the Quick widget is being executed. What that means is that there's a wall between Quick and C++ even if you are instantiating Quick widgets from C++.

While Quick widgets technically share memory space with the rest of the app code, any sort of UI behavior is expected to be handled by JavaScript, which doesn't run in the same memory space, and of course it's not going to in any case because it's not C++. So when data is shared, it has to be type converted, which can become a problem if you even slightly wander off the beaten path:

https://doc.qt.io/qt-5/qtqml-cppintegration-data.html#conver...

If you could elaborate on why I'm wrong, I'd certainly appreciate it. It's been about 3 months since I decided to entirely ditch anything involving Quick/QML, so I could be easily misremembering aspects of it.

In no way am I saying that someone shouldn't use Quick if they find that it works well for them. I find Quick's argument versus nearly all alternatives to be lacking. The primary argument against Electron is that it's bulky, and I think that's absolutely the case. The argument for Electron, however, is using the full web stack, which everyone knows how to use, and if you need performance to use WASM and workers, and that makes a lot more sense to me than something that even most C++ devs aren't familiar with that still forces you into dealing with all of Qt's compiler quirks.