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 :P) 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. 😉

This is coming about two weeks later than I would have liked, so the next pre-release is likely to come in two weeks to make up. Similarly, the monthly bugfix release for Muon Suite 1.3 is two weeks late. For that, I’ll likely just skip this month and release 1.3.2 in two weeks, as there haven’t been any serious bugs that need immediate attention. (Thankfully)

Anyways, I am proud to announce the first alpha release for Muon Suite 1.4. The Muon Suite is a set of package management utilities for Debian-based Linux distributions built on KDE technologies. Packages for Kubuntu 12.04 “Precise Pangolin” are available in the QApt Experimental PPA. Here’s what’s new:

Muon Discover

Muon Discover is the experimental new frontend in the Muon Suite. It was written by Aleix Pol Gonzalez as part of his employment at Blue Systems, and it’s pretty nifty. You can read more about it here.The idea is to create a Muon frontend that makes finding new software super-simple, and doing so with a little bit of flair. It’s no secret, that even though the existing Muon Software Center has some “bling” here and there, the interface is somewhat spartan.

Muon Discover will eventually replace the Muon Software Center, but not just yet. Muon Discover is young, and its interface is written entirely in QML. KDE has not issued a set of comprehensive UI guidelines for QML usage on the desktop, and currently Muon Discover is using the Plasma QML components for several of the controls in its interface. While we wait for a set of guidelines, the classic Muon Software Center will remain the default application installer, allowing Muon Discover to mature in the process. The QML Desktop Components (slated for release sometime around Qt 5.1 or 5.2, or so I have heard rumored) and KDE Frameworks 5 will likely be a big part of KDE’s QML standardization, so expect Muon Discover to replace the Muon Software Center in around that time period.

Muon Software Center

With all the buzz around Muon Discover, you may think that nothing has been done with the Muon Software Center. Well, never fear, as there are several cool new features and user experience improvements that have been made for Muon Suite 1.4.

Thanks to work done by Aleix, the Muon Software Center no longer has to reset the view back to the main page when it reloads the APT cache. This provides for a much smoother experience whilst installing multiple applications.

A progress view has been added for displaying currently running and pending transaction.

All Muon frontends now use the KDE proxy, if set. (Before it only used the system proxy and APT proxy settings) Priority goes: KDE proxy, APT proxy, system proxy.

Additional pages of application reviews can be fetched now.

A busy throbber has been added to the main page to provide feedback during launch.

Application views can now be sorted by Name, Rating, Buzz and search relevancy.

By popular request, non-application packages can be toggled for application views. (Though you’re still probably better off using the Muon Package Manager for package management.)

Ratings are cached locally so they can be accessed in the absence of an internet connection.

Muon Package Manager

The Muon Package Manager has not been forgotten, either. Highlights for the 1.4 release mainly include tools for better handling Multi-Arch packages on 64-bit systems.

By default, when a package is available for both the native and foreign CPU architectures, only the native package is shown. Installed packages of any architecture are shown. This means no more duplication of most every single package in the archive polluting the Muon package view. 😛

A new architecture filter has been added, allowing you to filter packages by their architecture.

The new Debian package categories “Education” and “Introspection” have been added to Muon’s category filters.

A package’s archive component is now displayed in the technical details tab. (E.g. universe, main for Ubuntu packages)

Muon Update Manager

Technical package items in the “System Updates” category are now displayed by their package name, as the description is not always descriptive enough.

Changelogs

Detailed changelogs for LibQApt and Muon can be found here and here, respectively.