Leading items

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.

Comments (10 posted)

Fitbit, Linux, and you

Fitbit devices are a family of wearable gadgets that track everyday health metrics (such as motion, calorie burn, and sleep cycles) on a minute-by-minute basis. There are certainly other hardware and software solutions to track such data, but most of them are "sportsband" products, focused on monitoring intense training sessions; the upshot of the Fitbit is that it monitors the contribution of everyday activity: walking, climbing stairs, and sitting still behind the keyboard. Since the latter activity consumes a large portion of the average software developer's day, the device has unsurprisingly attracted a following among programmers. But as is often the case, Linux users have some hurdles to clear in order to make use of the product.

Fitbit devices work by logging time-stamped readings from internal sensors; the current models incorporate both accelerometers and altimeters, tracking typical foot traffic. By associating the movement data with some basic facts about the size of the user, secondary statistics like calorie count are calculated, and some logic is used to smooth out the results and determine when a wearer is (for example) driving on the autobahn rather than running. The sensors themselves are not unique — plenty of smartphones ship with similar offerings — but the devices have gained a loyal following thanks to their low power consumption, small size, and relatively rugged construction.

Sync

Unfortunately the company releases support software only for Windows and Mac OS X. Support software is required because the devices are designed to offload their logs periodically to servers running at fitbit.com, which provides a free web service where users can track their individual metrics over time and compare it against other users. The early Fitbit models came bundled with a USB "base station" that connected wirelessly to the Fitbit devices using the ANT protocol; every so often when the device was in range it would synchronize the latest activity readings to the web service.

For that first generation of hardware, there is an open source solution for Linux users. In 2011, Kyle Machulis released libfitbit, a Python tool that supports pulling data off of the first generation Fitbit devices and uploading it to the official web service. In addition to pushing the device's data logs upstream, libfitbit also saves them locally in plain text format. The library does not support the altimeter sensor introduced with the Fitbit "Ultra", however. Machulis has subsequently created an umbrella project for libfitbit and an array of related health-monitoring device projects called OpenYou — he does not appear to be actively developing it, but there are several forked branches on Github that introduce improvements.

In mid 2012, Paul Burton started another Fitbit sync project called fitbitd that re-implemented libfitbit in C and ran the synchronization service as a daemon, with the client connecting to it over D-Bus. Fitbitd also added support for the Fitbit Ultra's altimeter sensor, allowing users to keep a close eye on their stair-climbing prowess.

But in late 2012 the company updated its line of tracker devices again, and switched radio protocols from ANT to Bluetooth Low Energy (LE). On one hand, the switch to Bluetooth should make implementing Linux support a little simpler, since ANT is proprietary. But on the other, only relatively recent kernels support Bluetooth LE, and thus far neither of the existing open source Fitbit sync projects have undertaken the task of implementing Bluetooth support. The new Fitbit devices do ship with a Bluetooth LE adapter for the PC, so the hardware is in place, but it may be a matter of time before the devices are widespread enough in the developer community for an effort at reverse-engineering the Bluetooth traffic to pick up steam.

Nor is there any great hope that the company will provide a Linux synchronization client of its own. Canonical's Jono Bacon reported in January 2012 that he had reached out to Fitbit about writing a Linux driver for the devices, but that after an initial expression of interest, the company stopped replying. Several application developers have asked about Linux support on the Fitbit API development list (most recently in September 2012) and were met with similar silence. In fact, Fitbit has still not introduced an Android synchronization app for the Bluetooth products; only recent Android devices support Bluetooth LE, but the company has released an iOS app that synchronizes with the devices over Bluetooth LE.

Data access

Of course, synchronization from a Linux machine is one aspect of using the device, but it is not the only one. For some people, the notion of uploading one's activity data to a remote service is anathema to begin with, and even more so if the data cannot be retrieved. The company offers an API so that developers can link other applications (such as those for jog/run planning or nutrition tracking) to the same user account. The API can be used to retrieve historical data from the web service in JSON format, but it only provides access to daily totals of the covered metrics.

At the moment, the most robust way to retrieve one's data from fitbit.com is through John McLaughlin's Fitbit for Google Apps script, a JavaScript tool that can extract the data directly into a Google Docs spreadsheet. It requires registering as a Fitbit application developer in order to obtain an authorization key, but Fitbit has recommended the script on the mailing list, so the company is clearly not opposed to the idea.

Through the official API, McLaughlin's script can download all of the daily totals from a user account going all the way back to the account's creation. The retrieval period is configurable, so users can run the script once to grab the complete history, then run shorter updates for subsequent daily or weekly additions. The result is a nicely formatted table of time-series data suitable for any inspection or graphing tool.

Daily summary data is certainly useful, but the minute-by-minute data is far more useful, particularly when it comes to analyzing patterns of activity over the course of the day. Libfitbit allows owners of the ANT models to save their full sensor logs locally, but so far Bluetooth device owners are out of luck. It is conceivable that the company regards high-resolution data as something it can monetize, since the basic data logging services is free of charge (Fitbit currently offers a paid "pro" version of the web service that somehow acts as personal trainer to the user; I was not intrigued enough by that idea to pony up the cash necessary to try it out).

In October 2011, Fitbit announced that it would begin allowing access to minute-by-minute "intraday" data "on a case by case basis to a limited number of developers". It is not clear what happened after that announcement. As of January 3, 2013 the company still has not opened intraday data to the public. The developer wiki mentions a Partner API which still requires that the developer contact Fitbit and ask for access, but the limited number of developers granted that access do not seem keen to discuss it.

Others have inquired on the mailing list about "raw" access to the device's sensor logs before they are uploaded to the web service. This would be even more appealing to the privacy conscious, and if one wants to do data mining personally it would be much faster to simply capture the data locally before it takes a round trip to the server. Here again Fitbit expressed interest in the concept, but has not acted on it subsequently.

Alternative hardware

Fitbit is far from the only player in the health-monitoring hardware market, but none of the other manufacturers are particularly friendly to Linux and free software either. Machulis's OpenYou project hosts a number of other libraries for communicating with personal monitoring devices, such as Nike's training-oriented Fuelband and the BodyBugg armband. Like libfitbit, both are designed to allow extraction of log data before it is uploaded to the relevant web server, but neither is actively developed. Similarly, there was a 2009-era effort to reverse engineer support for personal monitoring devices manufactured by BodyMedia, but it has not been updated in several years.

The "Up" hardware devices from Jawbone offer a slightly better experience. There is no Linux software available, but the full data set can be downloaded from the web service in CSV form. Motorola's motoACTV is an Android-based wristwatch with health monitoring features, and it is possible to root the device and side-load third party applications. Perhaps the strangest entry in the field is the Zeo line of sleep-monitoring headbands. The company released an official library to decrypt the logged data and export it to CSV, and a separate project to access the raw Zeo data in real-time. Although it was initially advertised as "under an open source library" it can currently only be accessed by agreeing to a severely limiting terms and conditions document. This dichotomy is perhaps a simple misunderstanding about licensing, but that does not resolve the situation for free software sticklers.

Another alternative that is frequently proposed is to make use of the position and accelerometer sensors already found in many smartphones. There has been at least one effort to write an open source pedometer application for Android, but both the reviews of the app and issues filed on the bug tracker reveal a key difficulty. Apparently many Android phones do not allow an application to access and record sensor data when the phone is in an inactive state. Since the goal is to track movement over the course of an entire day, this can make the app useless if one's phone manufacturer choose to enable this restriction.

Exactly what Fitbit plans to do with the API and with raw sensor data remains an open question. The company previewed another set of new devices at the Consumer Electronics Show in January 2013, but did not announce changes to the developer program. Consequently, Linux users in possession of the newer devices will need to start capturing and decoding Bluetooth LE traffic in order to make use of their hardware. The good news is that so far all of the Fitbit models successfully reverse engineered appear to use the same data format. The bad news is that capturing and reading Bluetooth traffic logs is such a sedentary activity.

Comments (9 posted)

A discordant symphony

Last May, IBM announced the completion of its long-awaited contribution of the source code for its "Symphony" OpenOffice.org fork to the Apache Software Foundation. More than six months later, there is no freely-licensed version of Symphony available, and some observers, at least, see no evident signs that any such release is in the works. A look at the situation reveals gears that grind slowly indeed, leading to tension that is not helped by some unfortunate bad feelings between rival development projects.

Apache OpenOffice (AOO) and LibreOffice are both forks of the old OpenOffice.org code base. There is not always a great deal of love lost between these two projects, which, with some justification, see themselves as being in direct competition with each other. That situation got a little worse recently when de-facto AOO leader Rob Weir complained about talk in the other camp:

Rob raised the idea of putting out a corrective blog post, but the project consensus seemed to be to just let things slide. Clearly, though, the AOO developers were unhappy with how the "usual misinformed suspects" were describing their work.

The specific suspect in question is Italo Vignoli, a director of the Document Foundation and spokesperson for the LibreOffice project. His full posting can be found on the LibreOffice marketing list. His main complaint was that the Symphony code remained inaccessible to the world as a whole; IBM, he said, did not donate anything to the community at all. This claim might come as a surprise to the casual observer. A quick search turns up Apache's Symphony page; from there, getting the source is just a matter of a rather less quick 4GB checkout from a Subversion repository. Once one digs a little further, though, the situation becomes a bit less clear.

The Apache Software Foundation releases code under the Apache license; they are, indeed, rather firm on that point. The Symphony repository, though, as checked out from svn.apache.org, contains nearly 3,600 files with the following text:

    * Licensed Materials - Property of IBM.
    * (C) Copyright IBM Corporation 2003, 2011.  All Rights Reserved.

That, of course, is an entirely non-free license header. Interestingly, over 2,000 of those files also have headers indicating that they are distributable under the GNU Lesser General Public License (version 3). These files, in other words, contain conflicting license information but neither case (proprietary or LGPLv3) is consistent with the Apache license. So it would not be entirely surprising to see a bit of confusion over what IBM has really donated.

The conflicting licenses are almost certainly an artifact of how Symphony was developed. IBM purchased the right to take the code proprietary from Sun; when IBM's code was added to existing, LGPLv3-licensed files, the new headers were added without removing the old. Since this code has all been donated to the Foundation, clearing up the confusion should just be a matter of putting in new license headers. But that has not yet happened.

What is going in here is reminiscent of the process seen when AOO first began as an Apache project. Then, too, a pile of code was donated to the Apache Software Foundation, but it did not become available under the Apache license until the first official release happened, quite some time later. In between there unfolded an obscure internal process where the Foundation examined the code, eliminated anything that it couldn't relicense or otherwise had doubts about, and meditated on the situation in general. To an outsider, the "Apache Way" can seem like a bureaucratic way indeed. It is unsurprising to see this process unfold again with a brand new massive corporate code dump.

There is an added twist this time, though. In June, the project considered two options for the handling of the Symphony code dump. One was the "slow merge" where features would be taken one-by-one from the Symphony tree; the alternative was to switch to Symphony as the new code base, then merge newer OpenOffice.org and AOO features in that direction instead. The "slow" path was chosen, and it has proved to be true to its name. Rob noted 167 bug fixes that have found their way into AOO from Symphony, but there do not appear to be any significant features that have made the move at this point.

One assumes that will change over time. The code does exist, the Foundation does have the right to relicense it, and there are developers who, in time, should be able to port the most interesting parts of it and push it through the Apache process. One might wonder why almost none of that work appears to be happening. If the project was willing to do the work to rebase entirely on top of the Symphony code, it must have thought that some significant resources were available. What are those resources doing instead?

Rob's mention of "larger pieces that will be merged in branches first" points at one possible answer: that work is being done, we just aren't allowed to see it yet. Given the way the AOO and LibreOffice projects view each other, and given that the Apache license gives LibreOffice the right to incorporate AOO code, it would not be surprising to see AOO developers working to defer the release of this code under their license for as long as possible. It would be embarrassing for LibreOffice to show up with Symphony features first, after all.

On the other side, it is not at all hard to imagine that some LibreOffice developers would be happy to embarrass AOO in just that way. Their complaint is not that IBM did not donate the code; what really makes them unhappy is that LibreOffice cannot take that code and run with it yet. It must certainly be frustrating to see useful code languish because the AOO project and the Apache Software Foundation are taking their time in getting around to putting it under the intended license. But IBM chose a channel for the release of this code that puts its ultimate fate under the control of those entities; there is little to be done to change that.

Competition between software projects is not necessarily a bad thing; it can motivate development and enable the exploration of different approaches to a problem. Thus far, it is not clear that the rivalry between AOO and LibreOffice has achieved any of that. Instead, it seems to create duplication of work and inter-project hostility. The grumbling over the Symphony source, which, meanwhile, sits unused by anybody seems like another example of that dynamic. With luck, the AOO developers will find a way to release the bulk of Symphony as free software, but one should not expect it to happen in a hurry.

Comments (169 posted)