Ubuntu's phone SDK and the QML component zoo

Canonical unveiled its Ubuntu for phones effort the first week of January with an announcement and a video demonstrating the user interface. For many developers, however, that launch was light on detail, and it was the somewhat less flashy Ubuntu Phone software development kit (SDK) that provided the interesting bits. The SDK highlights QML as the UI toolkit of choice — a fact which has attracted attention from other QML-based projects like KDE's Plasma Active and Jolla's MeeGo derivative Sailfish OS who showed an interest in collaborating on a common API. QML has been the application framework for several free software mobile phone platforms in the past — including some that fizzled out in high-profile fashion; perhaps a collaborative approach is the missing piece.

The Ubuntu Phone SDK

The Ubuntu Phone SDK is provided as a set of .deb packages in a Launchpad Personal Package Archive (PPA), which makes installation a snap for people running Ubuntu or downstream distributions, but a bit of an open question for those running something else. Source is available from Launchpad, but users on RPM-based systems may find satisfying the bleeding-edge dependencies a hassle. The packages include a set of Qt component libraries, plus some demos, examples, and the associated documentation. The development tools are the standard Qt set: the Qt Creator IDE and a QML viewer for interpreting and testing QML code itself.

QML is a JavaScript-based language designed for use in writing application user interfaces. It was introduced in Qt 4.7, coupled with a QtQuick module that defines a basic set of building blocks — graphics primitives like rectangles, gradients, borders, and images; text handling elements like input fields and form validators; animation and transition elements; and an assortment of list, transformation, and state handling elements. Although QML and QtQuick are frequently associated with smartphone development thanks to MeeGo, they are not specific to the mobile space.

The Ubuntu Phone SDK builds on top of the QtQuick base with its own set of components that define application interface elements (such as buttons, tabs, scrollbars, and progress bars), more specific elements for use with lists (such as headers and dividers, and separate elements for those list items that can take one value and those that can include multiple values), and navigation elements geared towards the latest in phone app design trends (such as "sheets" and popovers intended to slide or spring into view and be swiped away by the user).

There is also a separate application theming framework in the SDK, although the documentation warns that it is still under development and subject to change. Currently, theming Ubuntu Phone apps consists of writing a foo.qmltheme file containing CSS-like rules, such as:

    .button {
       color: item.hovered ? "orange" : "#ffcc99";
    }

which are then referenced in a separate file that defines the look of the specific elements used in the app. For example, a Button element would refer to the color above with itemStyle.color and pick up the value #ffcc99. As one would expect of the visually-conscious Canonical, indications are that Ubuntu Phones will ship with a set of pre-defined themes to provide consistency.

Other QML platforms

The theming model is not a big departure from the one used by QtQuick, however. The new QML components defined by the SDK are the principal difference between developing an app for the Ubuntu Phone platform and developing one for any of the other QML-driven platforms. That list includes not only Sailfish and Plasma Active, but RIM's Blackberry Cascades and Nokia's still-alive efforts for its MeeGo Harmattan and Symbian platforms. Each of the other platforms has defined its own set of add-on components as well, a fact that did not escape the attention of mobile developers.

Johan Thelin wrote a blog post on January 3 comparing and contrasting the available add-on toolkits by looking at just one component, the CheckBox element. A checkbox is used to capture a binary selection, but Thelin outlined five properties (text, checked, enabled, pressed, and hovered) and three signal types (onCheckedChanged, onClicked, and onPressAndHold) that vary between the available component libraries. This potentially forces developers to rewrite their applications to support more than one QML-based platform.

Nevertheless, Thelin, concluded, "as the concepts seems similar, the work to create a cross-platform set of components wrapping the components of each platform should not be an impossible task."

Canonical's Zoltán Balogh was evidently of similar mind, and popped into the Plasma Active IRC channel on January 9 to discuss the idea with the KDE and Sailfish developers. Subsequently he wrote up the outcome of that discussion on the Qt Components mailing list. Balogh, Marco Martin and Aaron Seigo from KDE, and Joona Petrell from Sailfish agreed to continue discussing QML components and APIs with an eye toward "collect[ing] all concepts in various projects" and a "consistent QML component and common API set." Vladimir Minenko from RIM agreed to participate in the discussion as well, as did several developers from Qt's current corporate backer Digia (who are working on a revised set of components to include in Qt 5.1).

One component set to rule them all?

The discussion on the Qt Components list then turned to the task of collecting information on the various components from each platform that were perceived to be of general interest. The list is growing at the Qt Project wiki, but agreement on the principle of cooperation does not make platform differences melt away.

Digia's Jens Bache-Wiig expressed some skepticism that coordination would reap big benefits, noting that the project had "tried this before with Symbian and Meego and partially failed while spending an amazing amount of time arguing over small issues." Nevertheless, Bache-Wiig was "optimistic that we can find at least some shared ground."

Martin Jones argued for defining a "minimal API" that omitted platform-specific properties and signals, but if the early discussions are anything to judge by, differences between the platforms may make even that task a tricky one. For example, Jens proposed an initial set of components consisting of Button, ToolButton, CheckBox, Slider, ProgressBar, TextField, TextArea, RadioButton, ButtonRow, Menu, ContextMenu, ToolBar, Switch, and BusyIndicator. But Alan Alpert replied that ToolBar, ToolButton, and ContextMenu could not be used in Cascades, because on that platform the system maintains tighter control over UI elements. "You don't create your own tool bar for your application - it creates the system tool bar for your application when you specify actions for it."

To be sure, RIM may have less market share today than it has in years past, but the other platforms differ as well. Martin Jones pointed out that Sailfish has no "tool bar" or "status bar" at all, and so far has no implementation of radio buttons either. Likewise, Canonical's Zsombor Egri replied that Ubuntu Phone has no "tool bar" either and has yet to make a decision about menus and context menus.

Of course, Sailfish and Ubuntu Phone are new platforms not yet running on released products. For that matter, the widely-anticipated Vivaldi tablet project using Plasma Active came to an abrupt halt in mid 2012. All three projects could decide tomorrow that tool bars are indispensable (or, for that matter, that text entry boxes are passé ... ). Still, it is a welcome sight to see the projects collaborating on the process of developing a component API. Seigo wrote approvingly about the discussion on his blog, saying

Further down in the same post, he hinted that the collaboration may extend beyond QML components to include "other aspects of the bigger puzzle such as common package formats and delivery strategies." The broad view, he concluded, was that sharing some level of API consistency, even if implemented differently behind the scenes, offered "a far more friendly and interesting story for developers."

Few would argue that offering a friendly and interesting developer story is not critical to the success of a new mobile platform. The bigger obstacle may be attracting hardware partners and mobile carriers — a feat that Ubuntu Phone, Plasma Active, and Sailfish all have yet to deliver to completion — but providing a partially-shared development story around QML certainly cannot hurt.

Then again, the promise of a device-neutral application platform is also one of the oft-repeated benefits of using HTML5 as a development platform. Here the Ubuntu Phone marketing materials do not paint as clear of a picture for developers. HTML5 is touted as an option for developing Ubuntu Phone apps, but so far the SDK and tutorials offer no help for HTML5 developers, and the supporting documentation is silent. Perhaps more is still to come (this is the first release of the Ubuntu Phone SDK, after all), or perhaps Canonical is simply waiting to see where its competitors in the mobile HTML5 game — such as Tizen and Firefox OS — head first.

---

(Log in to post comments)