PureQml's Python-based QML Compiler - A tempting starting point for Kea's UI-Definition Compiler...

I know I already have too many open / unfinished projects (and a bunch more un-started yet)...

BUT, I was "doing the rounds" again after work today on HTML/CSS alternatives to doing web-deployable apps, and ended up looking at the QML situation again...

(Unfortunately, while I'll try to finish current project using HaxeUI, I'm running into too many weird update bugs + other hard-to-overcome limitations that I'm currently inclined to go back to looking for another solution for the next test project / whatever will be used to implement Parus)

 

TLDR:  Am again getting itchy hands to jump back into building my "Kea" language compiler in Python (possibly either hacking OR deriving significant inspiration from "PureQml"'s Python-based "QML-subset -> HTMl5 / Javascript" compiler), but focussing first on the QML-like UI-definition syntax   (before adapting the wider language later, and for non-web backends for those other parts)...

 

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!)

QML Tip: Making one ShaderEffect use the output of another ShaderEffect

I've been doing quite a lot of work in QML lately for one of my research projects. Recently, I ran into some problems when trying to use ShaderEffects to actually apply them to "interesting" widgets/elements (i.e. on to anything that's not an Image and/or is more complicated than just a simple Rectangle). This post is just a quick guide to some of the key issues here (and ways around them), since it's not exactly that obvious from the documentation that this is the cause/solution, and no other hits come up about these issues...

QML in the Wild

In my previous post, I included a brief rant on the current trends of using raw HTML+JS+CSS clusterf***s to develop applications. After doing some more digging, it turns out that a group of devs in the KDE/Qt communities have had the very same thoughts, and have actually done something about it...

Introducing QMLWeb: A JavaScript port of the QML engine for use in web browsers. From the tests I've played with, it is somewhat functional already (though I'm sure it still has many rough edges if you poke hard enough). Hopefully in time this does get somewhere. In the meantime, I know what I'll be playing around with next time I'm looking at hacking together a webapp :)

----

It turns out that there are also some other interesting projects going on out there with QML - All of which are exactly the kinds of things I'd been dreaming about for a while. A prime example is SlideViewer (an as-of-yet unreleased system, which the guys at KDAB have been teasing us with). It certainly shows promise of finally being that tool for defining dynamic presentations where you can bundle up certain assets so that you can progressively build on them (vs having to create new copies on each slide, and manually propagate changes to each). Though their variant probably doesn't do this, there's nothing stopping us from doing it in standard QML :)

----

Finally, to conclude our little tour of QML-based systems in the wild, it turns out that it is already in wide use for things like the KDE "Plasma" widgets and Ubuntu's Unity Launcher. Then again, I should have guessed that that would be the case, as it's clearly battle-hardened in ways that Gnome/GTK simply isn't :P

Experiments with QML and Vim

This weekend, I've been having a lot of fun playing around with QML, and doing so in Vim (instead of my usual Notepad++). Chances are that you probably haven't heard of QML before (or if you did, your projects at the time wouldn't have really benefited from it, given that it does have limitations when it comes to being able to use standard widgets).

QML is basically a "declarative" language for defining dynamic UI's, built on top of the Qt Framework. It's syntax is like a nicer version of CSS, with the ability to throw snippets of Javascript in when needed to define small bits of custom logic when needed, and (if it's hosted via PyQt) you can even code up any of the more "tricky" or substantial logic in Python, then use the PyQt QObject bindings to make this available to your QML code.

Although it doesn't come with a fully fleshed out widget set that you can use (though apparently, this is only true for the PyQt4/Qt4.x that I'm still using, as they've developed a set of widgets for that purpose in Qt5), it more than makes up for that in terms of what it enables you to do instead.

Basically, if you're looking for a lightweight domain-specific language for defining/prototyping little graphical scenes, complete with dynamic behaviour (i.e. procedural animations, animation effects, and transitions in response to user input), and the ability to compose/package up you creations as reusable assets, look no further. This toolkit is for you!