More (mis-)adventures in Qt Quick land

There’s no escaping that Qt Quick, sometimes also referred to by its language QML, has become the major focus of the framework. At least until the company decides to drastically change course in Qt 7. There will always be a place for QWidgets-based UI and C++ (everything compiles to C++ anyway, more or less), Qt Quick is really being pushed as the future of building user interfaces, especially for touch, mobile, and embedded.

A few years back, I tried playing around with using Qt Quick for rapid app prototyping by creating some reusable components and I wanted to build upon that by prototyping some non-conventional and even fictional user interfaces from prototype devices and concept videos. I didn’t get far with my limited knowledge of Qt Quick and was only able to implement an extremely crude version of MeeGo’s column-based home screen (a dream from long ago, don’t ask).

Inspired by my success (dripping with sarcasm), I ventured to try out other unconventional UI ideas that I had that I presumed would probably be easier to pull off in QtQuick compared to a traditional widget-based application. Especially since QML is always advertised for in-vehicle HUDs and instrumentation control panels.

Lastly, there was this sort of program I’ve long been thinking of, more as a fun and whimsical nod to some anime of my childhood. Yes, it’ll probably bring back not so fond memories of Clippy, but eh. Like I said, mostly for fun (for now).

I wish I could report that I have become a QML Qonvert (SCNR). I’m still on the fence about the whole Qt Quick matter, regardless of whether it’s the future or not. It’s probably possible to implement all of the fancy animation and touch-based gestures in C++ (since that’s what Qt Quick uses underneath anyway), but it will be like bending over backward just to have a “pure” C++ implementation. And since KDE Plasma, both desktop and mobile, are pretty centered around Qt Quick, the argument is pretty moot for a KDE developer working on those parts.

It’s not that I found the experience terrible. In fact, I’ve probably grown a bit fond of declarative programming, at least for some parts that make sense. I also appreciate how easy it is to play around with non-traditional widgets and controls or even make your own using QML, something I think would have taken me more than a day to pull off in C++ given the same level of proficiency (read: noob).

That freedom and flexibility, however, do come at a price, when the things you’ve taken for granted on the QWidgets side of the fence now become critical knowledge. Positioning, layouting, parenting, and the like have been particular stumbling blocks. They’re easy for the most common use cases but then become exponentially more complicated once you step outside of those. And don’t even get me started on how Qt Quick still lacks a proper tree view after so long.

My main takeaway? Qt Quick is almost like a separate and independent framework of its own, just one that’s built on top of Qt’s core classes. It almost shares very little in common with the widget-based paradigm that it’s probably best to treat it as an entirely different beast rather than just “another way” to develop Qt applications. In other words, it’s definitely something I’ll have to invest in learning deeper, as deep as I tried learning Qt ages ago. And considering the kinds of applications I want to write or am interested in, it is, as one purple dude said, inevitable.


One thought on “More (mis-)adventures in Qt Quick land

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.