Wednesday, December 22, 2021

QML Quirks - A laundry list of bizzare happenings, bugs, and dodgy incomplete crap

Over the past few years, I've built a fair few UI's using QML (Qt's DSL for writing UI code) - proper ones, including one for a mission-critical / safety-of-life application, and another powering the tool to be used across a large group of non CS types. In other words, things that had to work, and not just be interactive "nice to have" toys (aka research prototypes).

Memorably, I was once asked during an interview whether I would recommend using QML and/or how it compares to using the more battle-tested QWidgets. At the time, I'd only really used it for a bunch of research prototypes (i.e. implementing HCI experiments to be exact), where it presented a great environment for implementing the kinds of dynamic non-traditional interfaces I needed. For that it was great and saved a lot of time. But, admittedly, it did also throw up a bunch of glitches (e.g. randomly sampling garbage from the wrong texture buffers / other applications even, particles not showing when chaining several scenes together but being fine when used in isolation, etc.). At the time, I could only attribute some of these to me perhaps trying to combine a few too many highly experimental techniques where perhaps the framework hadn't been tested so great.

However, knowing what I do now, I would strongly recommend that unless you were building something non-mission critical, and where the thing is loaded with animations / dynamic effects, that you really shouldn't be using it. Sure, you may be able to knock out a prototype quite quickly - but at some point - often at ill-timed moments, you will randomly stumble across one or more intractable bugs / quirks from left field that have you scrambling to rewrite / refactor the whole lot.

 

Disclaimer: Just to be clear - I generally do still like the idea of the QML language, and I think it does many things right. However, there are also many ways in which the "declarative paradigm" is really awkward to work with (*ahem* creating dialogs / temporary items / sequential-flow-based-types / etc.) 

More disconcertingly though, implementation-wise, it is seriously lacking in quality / completeness / stability, etc. in enough ways that mean that I cannot in good conscience recommend any new greenfield projects to start adopting it now.

(Plus, the fact that the embedded scripting / logic programming language it uses is Javascript... blegh!)

[Web Browser UX Proposal] Bookmarks 2.0 - Load / Save "Page Snapshots" Instead of "Bookmarks"

It's been a while since I last posted anything here. Since then, the Blogger editor UX has changed a bit (and I'd say, quite detrimentally in a few key areas) making it a pain to write + post anything here. At some point, I'll likely end up converting this blog to a statically generated format, so I'll have full control over the longevity + setup of it, as that's been a recurring issue with Google properties for a while now.

Speaking of UX issues, here's a proposal for a way to solve one of the bigger issues we have with web browsers currently. Specifically, it aims to improve the usability of bookmarks, reduce the reliance on having to keep so many tabs open for certain reasons, and may also help the Internet Archive in its valiant efforts to keep on top of the endless churn of the web.

Note: While writing this, I've been considered setting up a web browser dev env to tinker with doing this myself (and probably fix several dozen other annoyances in the process) - but that's probably just holiday-mode brain trying to take on too many side projects that will have to get dropped as soon as the daily work-year grind starts up again.

Anyway, just thought I'd post this here to get a bit of visibility onto it.