0 votesclick to vote up

Jonathan Thomas: My Thoughts on QML and the Desktop Published May 19 2012 via RSS

planetUbuntu

As we all know, Qt5 is approaching. The “big new thing” with Qt5 is the introduction of QtQuick/QML for writing dynamic user interfaces. If you are (somehow ) unfamiliar with QtQuick and QML, you can read up about it here. The rest of this post assumes that you know something about Qt Quick.

Qt5 is imminent, with a release set for sometime within the next few months. But as of currently, there seems to be several questions that remain in regards to QML. I have encountered several questions, some directed at me, such as “Why would a desktop application want to use QML?”, “How will traditional desktop applications be able to use QML?”, “How will QML applications integrate with KDE and its existing applications?”, and, more specifically, “How will Muon Discover integrate with KDE since it is using QML?”. In this post I will attempt to answer these questions, with my opinions and thoughts on the matters.

Why would a desktop application want to use QML?

Traditionally, user interfaces for applications have been written to be composed of discreet “forms” or “pages”,  with each form containing a (mostly) static collection of controls called “widgets”. To present new forms to the user, an application would either present the new form as a separate window/dialog, or replace the form in the main window with a new one entirely, using a widget stack to contain the forms.  These interfaces were coded either in straight C++ (or with language bindings), or by compiling XML files created with a WYSIWIG-esque interface designer. A common set of widgets is shared among applications of a particular toolkit. (Be it Qt or Gtk, etc) This, along with theming, allows for very tight graphical consistency between applications written in the same toolkit.

Now, there is nothing particularly “wrong” with the way things currently work, but that does not mean things couldn’t be better. Animations are a useful tool with regards to usability. Aside from looking slick, user interfaces that morph gradually are easier for the human mind to “track”, as opposed to instantaneous change. But until the advent of QML, providing animations (and fluid interfaces in general) with the traditional static widget-driven user interface, you had to roll your own. Qt did provide several APIs within the last few releases to provide animations/effects within QWidget-based interfaces, but even then doing animations and graphical effects was not exactly trivial to “get right”. And even when using these APIs, the effects’ drawing performance is tied to the painting backend in use with Qt, which can be slow (e.g. the old X11 Qt painting plugin), or at the very least can’t take advantage of the dedicated graphics hardware of the modern computer.

In short, QML makes it very easy to write fluid user interfaces, while retaining speed. The advantages expand well beyond the mobile application sphere, and represent a new way to do GUIs.(tm) [/marketing mode]

How would a desktop application use QML?

But what, specifically, would you use QML for within a desktop application? Aside from generally animating the interface, how would QML be used to provide advantages of the current QWidget paradigm?

For one, it makes it much easier to present non-control media such as pictures in an appealing fashion. Take for example, the slideshow for featured items in the home page of Muon Discover. It is written in a mere 126 lines of QML, and provides navigation between featured items, animated item switching, fading in new items, and it automatically pans around screenshots that are too big to fit in the banner. Doing the equivalent with QWidgets or even QGraphicsItem and friends would be a lot more involved, requiring lots of custom painting an animation code, with potentially worse performance.

Aside from the presentation of things that are strictly media (though to be fair, clicking on the aforementioned slideshow will take you to the app’s page), QML can also aide in the creation of user controls that themselves can incorporate media and animations.

Take delegates for list views as an example. If you want to go beyond the simple icon-and-text that the default Qt list view delegate offers, you must subclass your own delegate and re-implement the paint function. Re-implementing the paint function requires you to do a lot of pixel math with a lot of code that, frankly, I never mastered. Whenever I’ve needed a custom delegate, such as for the Muon Software Center and Muon Package Manager, I’ve resorted to searching lxr.kde.org for delegate subclasses, searching for a delegate that kind of does what I want, and tweaking that until I get something useful. At the end of the day, even creating a delegate that paints an icon, two lines of text, and a rating widget takes around 300 lines of code. You get a whole lot of control, at the expense of a whole lot of hassle.

300 lines of code for this itemview delegate

With QML, a similar listview delegate takes only a bit more than 100 lines of QML, without forcing the UI designer to do tons of pixel-based positional calculations within the QML script. With it being so easy to make itemview delegates in QML, Aleix was even able to create a second “icon grid view” delegate that incorporates animation within the delegate to show different information when moused over, as seen in his video here.

On the issue of integration and consistency

One of the strengths of KDE is how well its applications fit together. Most every applications share exactly the same set of controls. (Buttons, list views, line edits, scroll bars, etc, etc) Similarly, these common controls all follow a common theme. The combination of these two provide a consistent experience common to all KDE applications, which makes it easier for somebody new to KDE to pick it up. If you learn how a combobox or list view works in one application, generally, you’ve learned how they work in all KDE/Qt applications.

This level of integration is not yet available in QML, which is why we’re holding off from replacing the Muon Software Center with Muon Discover until things change. As of now, Qt does not offer a set of common components like we see with the current set of QWidgets. There is the set of common QML Elements that provide a rudimentary set of common components, but it’s nothing as extensive as what we have currently. If you need a UI control in QML, currently you must roll your own. Doing this results in un-integrated controls reimplemented by each application that potentially do not share a common theme. Muon Discover is currently using Plasma’s QML components, which while providing graphical and widget-level integration with Plasma and making Muon Discover fit in on a Plasma Active system, does not provide integration with most of the other QWidget applications on “the desktop”.

The solution to this does appear to be coming, however, in the form of the Qt Desktop Components for QML. The QML Desktop Components provide a set of UI controls analagous to the ones available with QWidgets. Additionally, they use QWidget theming, allowing graphical integration as well as behavioral integration with QWidgets. You can see them in action in KAlgebra Mobile here. Through the use of desktop components, we can make applications that utilize all the benefits of QML while retaining integration with the rest of the desktop. The only caveat is that the desktop components haven’t actually been released yet. Previews can be found at their Gitorious site, and we even have a git branch for Muon Discover that (partially) uses the desktop components. I’ve not heard a concrete release date for the QML desktop components, but seems like they will be The True Way Forward ™ for QML on the desktop.

Conclusion

I feel very strongly about consistency, so to re-iterate Muon Discover will not displace the Muon Software Center until we have a way to integrate with the rest of KDE. QML does, however, provide a very powerful way to create attractive, easy-to-use interfaces without too much effort. While we wait for a solution for the desktop to become available, we can continue to hack on Muon Discover and allow it to mature. And hey, it already integrates well with Plasma via the use of the Plasma QML components, so perhaps in the nearish future (with a bit of work to make Muon Discover touch-suitable) you could find Muon Discover on a Kubuntu Active spin near you.