Ubuntu and Qt, MeeGo and GTK+

The waning days of January brought two intriguing developments in the world of Linux distributions and their application frameworks. On January 18th, Canonical's Mark Shuttleworth announced that starting with Ubuntu 11.10, the distribution would ship Qt libraries in the base ISO image, and was underwriting some development work to make it easier for Qt applications to tie in to the rest of the desktop. That news largely overshadowed the GNOME Foundation's January 17th announcement that it had hired Igalia to integrate the GTK+ toolkit into the MeeGo Handset platform, and to merge components from Maemo's Hildon framework upstream into GTK+ itself.

On the surface, both efforts mark the availability of a new framework in a distribution that up until now has seemingly shipped entirely one side of the "Qt/GTK+" fence (Ubuntu being GNOME-based, and MeeGo being Qt-based). But neither situation is as clear-cut as that. Canonical has always provided Qt libraries and Qt-based applications through its repositories — just not on the Ubuntu ISO image itself. MeeGo officially supports Qt as the third-party application developer platform, but it also includes many components from the GNOME stack.

Ubuntu plus Qt

Shuttleworth introduced the Qt announcement by saying that ease of use and effective integration are the key values in Ubuntu's user experience, and that although the distribution has historically given very strong preference to GTK+ applications, a toolkit itself is merely a means to an end. When evaluating whether or not to make a particular application part of the default install, he continued, the questions to ask are whether it is free software, whether it is "best-in-class," whether it integrates with the system settings, preferences, and other applications, whether it is accessible, and whether it looks and feels consistent with the rest of the desktop.

Although there are plenty of excellent Qt applications that meet most of those requirements, the sticking point in previous releases has been the fact that GTK+ applications all use the same centrally-managed preferences store (dconf), while Qt applications typically use KDE's. Aside from storing its own preferences in a separate location, a Qt application on Ubuntu does not have access to system-wide settings that affect its integration — font rendering, sound, peripheral settings, etc.

To fix this, Canonical has contracted developer Ryan Lortie to write dconf bindings for Qt. It is not yet clear what form Lortie's dconf work will take — some have suggested Qt's QSettings, others KDE's KConfig. Currently the plan for Ubuntu seems limited just to shipping Qt libraries in the 11.10 ISO, but Shuttleworth left the door open for individual Qt-based applications to be included, too.

It does not sound like Ubuntu is considering core KDE applications in this category, but Qt applications. As Ryan Paul pointed out at ars technica, KDE applications "come with heavy KDE infrastructure dependencies and have KDE-centric behaviors," while Ubuntu continues to develop a GNOME-based desktop. On that topic, Shuttleworth even explicitly said that the decision to add Qt libraries was "in no way a criticism of GNOME," and reiterated that the distribution is making GNOME the focus of its design work. Nevertheless, some in the comments on Shuttleworth's post appeared to read the announcement as a "move" away from GNOME and towards KDE.

There were also vocal reactions from many KDE supporters that seemed to interpret the announcement as an attempt to coerce KDE developers into altering their code to support Ubuntu specifically. KDE's Aaron Seigo called it "dictating" to Qt developers and "not that much different from saying that Qt apps should just use Gtk+ for rendering so they fit in better." He also said that KDE and Qt have led the way in defining standards (citing freedesktop.org), and contrasted the project with Canonical, saying the company had "historically taken rather heavy-set stances that worked against" giving developers the best choice of applications.

Seigo's blog is frequently inflammatory, of course — ironically, several commenters on Shuttleworth's announcement linked to an older post by Seigo in which he lambastes freedesktop.org as "messed up" and a "self-important disappointment" for developing dconf in the first place. A lower-key criticism came from openSUSE's community manager Jos Poortvliet, who referred to the project as "creating a special Ubuntu world" by keeping the dconf bindings Ubuntu-only, rather than integrating them with upstream GNOME and GTK+.

But it is not clear whether Lortie's dconf work truly will remain Ubuntu-only, or whether it will be embraced upstream — there are still simply too many unknowns. Ubuntu's community manager Jono Bacon posted a FAQ entry about the plan, but it offered no elaboration on the development process itself. Jim Campbell pointed to the contributor agreement that Canonical uses for other projects as a concern and suggested that it might cause the work to be Ubuntu-only.

Campbell also raises another interesting question in his post: whether GNOME developers will be enticed to write applications with Qt in general. Despite long-standing divisions between the Qt and GNOME frameworks, there is no reason an application must use GTK+ for its widget toolkit simply because it uses other GNOME libraries. It rarely happens, but that may be because no major distro installs both Qt and GTK+ libraries by default. A fact frequently overlooked in the discussion is that when Ubuntu ships both, it will be the first major distribution to do so. Even those distributions like openSUSE that offer users a choice of desktop environments at install-time typically install either one complete stack or the other.

Having both frameworks available at the same time could indeed make mixed-framework applications possible, which Paul also observed. That prospect does not thrill everyone, though. Blogger Martin Espinoza told LinuxInsider it amounts to more bloat and more dependencies in an already tight ISO image. Several suggested to Shuttleworth that it may be time for Ubuntu to move from a CD to a DVD image to cope with the increasing bulk of the default install.

MeeGo plus GTK

While the Canonical project is an example of a distribution choosing to draw in another framework, the GNOME Foundation's announcement is the opposite: a framework cozying up to a distribution. Prior to MeeGo's birth, the Maemo distribution for Nokia handsets was based primarily on GNOME frameworks, including the GTK+ widget toolkit. After Nokia's acquisition of Trolltech, however, the company changed directions, and rewrote Maemo 5 with Qt.

Things got more complicated with the combined Maemo-plus-Moblin-equals-MeeGo stack. The MeeGo project officially recognizes Qt as the third-party development platform on which the SDK is based, and around which its marketing to device makers centers. But the overall MeeGo architecture still depends heavily on other, non-Qt components, including Cairo, Clutter, Pango, GConf, Telepathy, GLib, D-Bus, GStreamer, ATK, and Evolution Data Server. So it should not be surprising that the GNOME Foundation was interested in funding development to bring the GTK+ portion of the GNOME platform to MeeGo as well.

The Foundation put out a call for bids in October of 2010, detailing three requirements: ensuring GTK+ applications would run on the MeeGo Handset UX (User eXperience), adding upstream components to GTK+ to facilitate running GTK+ applications on MeeGo, and merging the functionality of Maemo's Hildon framework into upstream GTK+. The contractor chosen in January's announcement, Igalia, is a contract company based in Spain that contributes to GNOME, GStreamer, WebKit, and other open source projects. In the announcement, the Foundation said that Igalia's application "focused the most on integrating elements of Hildon into GTK+ upstream," and that this emphasis would make it easier to port desktop-based GTK+ and Maemo applications to MeeGo.

Hildon is the application framework originally created by Nokia for Maemo. It includes desktop components, an input system suited for touch-based and onscreen keyboard input, finger-friendly menu and user interface widgets, kinetic scrolling, and other handset-oriented features. Igalia started working on Hildon when Nokia shifted its Maemo attention to Qt. The GNOME-funded work will support two developers at the company, Claudio Saavedra and Carlos García Campos.

The announcement and the Igalia site are both short on details, but it does sound like the emphasis will be merging existing Hildon and mobile technologies into GTK+ proper, rather than maintaining a separate project. With the MeeGo project's self-proclaimed "upstream first" philosophy, that approach would make the most sense. But it is the reaction from MeeGo that is the biggest unanswered question. The project's support for Qt as a development framework is enthusiastic — which is what one would expect from Qt's corporate parent Nokia.

Whether or not the project will support GTK+ in future releases remains to be seen. When MeeGo launched in 2010, the architecture diagram included both widget toolkits, though it does not anymore. The FAQ still states that MeeGo will include GTK+, but it is absent from the developer documentation.

Rumors are that the Clutter-based interface on the Netbook UX will be replaced. Of course, the Netbook UX is already more GTK+-heavy, including desktop GNOME applications like Evolution, Banshee, and Empathy. Perhaps the real story there is merely how different the various MeeGo UXes really are: they are not simply finger-, keyboard-, or remote-based recasts of the same interface; they have very different components. The Netbook UX is still largely derived from Moblin, and the Handset UX comes from Maemo 5.

There is nothing wrong with that approach; MeeGo is most accurately described as a meta-distribution encompassing several distinctly different siblings. But at 2010's MeeGo Conference in Dublin, one of the key messages was that all MeeGo releases would come with a compliance-testing guarantee: an application that runs on one MeeGo device will run on any MeeGo device.

That guarantee rested largely on outside developers using Qt and QtMobility as the development framework, so one has to wonder how the project — particularly the program managers — will react when presented with a revamped and actively-developed GTK+ for Handsets that competes for developer attention with the official solution. MeeGo's governance structure is always described as a meritocracy, where anyone can contribute. Hopefully, as is true on the desktop, that will prove true, and developers can take their pick of frameworks.

Oranges and Oranges

In the space of 24 hours, a GNOME-based distribution announced that it would start shipping Qt libraries enabled, and the GNOME Foundation announced that it would pay to develop GTK+ for the Qt-based MeeGo. It would be nice if the open source community saw both situations the same way: as big players in the Linux ecosystem doing their best to give developers more choices for how to create their applications.

In neither situation does the new development work indicate that the distribution is "moving" away from one framework to the other. Unfortunately, however, the often dichotomous KDE-versus-GNOME mindset contributed a distracting amount of noise to the discussion. Partly that is because people erroneously equate Qt with KDE, and just as erroneously equate GTK+ to Qt. Neither comparison is apt. GTK+ is just the widget toolkit; the proper parallel to Qt is the entire GNOME Platform. KDE is a distinct project from Qt, and is an environment built on top of the Qt platform.

It also does way more harm than good to speculate on things like Ubuntu "switching" from GNOME to KDE (or even from GNOME to Qt). Commenters pointed to the 2D, fallback version of Unity as the secret reason why Shuttleworth decided to add Qt to 11.10. I personally suspect is has more to do with Shuttleworth's recent infatuation with Scribus, although I lack hard evidence. Considering that no specific Qt applications have been discussed for inclusion, it seems like the Qt inclusion is designed more to reach out to the "opportunistic developers" Ubuntu wants to attract than it is to bend existing Qt developers to Canonical's will.

Shuttleworth hits the nail on the head when he calls a toolkit a means to an end. That's inherent in the idea of a "toolkit." Whatever you may think of Canonical's motivations in funding Qt dconf work, or the GNOME Foundation's motivations in funding MeeGo GTK+ work, both projects are going to be empowering for developers — which is what the community usually cares most about in the long run.