Re:Leaving The Qt Company
by Kelteseth on Wednesday May 18, 2022 @09:34AM
(#31422570)
QML is Qts innovation. The declarative way to write a UI is unmatched IMHO when comparing to Unreal, Godot or the Web. Still, QML has a _lot_ of other little problems like bad tooling (no autoreload, unusable designer) and often broken type system where you can assign invalid properties, and it will silently fail.
[ Parent
| on HN ]
If by "silently fail" you mean "entire segments of your UI disappearing" then yes.
Re:Leaving The Qt Company
by nyanpasu64 on Wednesday May 18, 2022 @06:47PM
(#31428589)
QML on the desktop is highly buggy. The menu bar doesn't close when you click on other windows (even after 10 years), it took a decade to create a half-decent Qt Quick Controls 2 file dialog, there were multiple tab order bugs where pressing Tab hung the app (in Qt Widgets it would instead highlight the wrong widget when you pressed Tab then Shift-Tab) and one of them was fixed after several years mere weeks ago (https://bugreports.qt.io/browse/QTBUG-87190), mouse scrolling (Flickable) works differently from Widgets (and scrolling twice quickly can travel 4 times the distance as scrolling once), on Android it drops frames even on a fairly high-end phone (Pixel 4a) and interactions feels uncanny-valley... I'm under the impression that you're almost not meant to use Qt Quick Controls 2, since KDE created their own Item hierarchy, rejecting Qt's own Flickable altogether.
Re:Leaving The Qt Company
by noahadavis on Thursday May 19, 2022 @02:43PM
(#31438463)
KDE still uses QQC2 and Flickable. However, we do workaround Flickable's deficiencies by filtering mouse wheel input on QQC2 ScrollViews and setting the content X/Y values so that it moves more like a view in Qt Widgets. It's not ideal. I hope one day I or someone else will be able to fix Flickable's behavior upstream.
Autoreload can be added quite easily, like in this Lisp binding, which has an example where even single file autoreload works, both on desktop and mobile, simultaneously:
https://gitlab.com/eql/lqml/-/tree/master/examples/advanced-...
It's also not truly declarative since you can observe ordering (and therefore your app may silently depend on imperative execution)
There's also performance issues with large amount of code, and last I checked, Qml doesn't really mix well with the traditional Qt widget and protocols (i.e. sometimes things are reimplemted in Qml under similar names, but with different behaviors)
>QML is Qts innovation. The declarative way to write a UI is unmatched when comparing to...the Web
What? Isn't HTML the daddy of declarative languages for UI ?
> Isn't HTML the daddy of declarative languages for UI ?
Not really. HTML is a way to create documents. It's closer to latex than QML. HTML + CSS + JS is used to create UIs, but it definitely does not match the capabilities of something like QML.
- JS is not needed to create UIs.
- CSS is used for styling, it is important but is not required.
Don't get me wrong, i think QML and XAML are cool and all, but HTML did this a long time ago.
HyperText Markup Language, but also have some UI elements/styles.