Inclusion of Qt in Ubuntu 11.10 is a win for developers

In an announcement published today on his personal blog, Canonical founder Mark Shuttleworth revealed that Nokia's Qt toolkit will be included as a standard component in future versions of Ubuntu. The move will pave the way for applications built with Qt to become a part of the popular Linux distribution.

Qt's numerous technical advantages, excellent cross-platform compatibility, and strong positioning in the mobile space are making it an attractive choice for third-party developers and commercial ISVs. Supporting Qt out-of-the-box on Ubuntu could help bring more software to the platform and will help to accelerate third-party application development. The move could be viewed as controversial, however—as a GNOME-based distribution, Ubuntu has historically been aligned with the competing Gtk+ toolkit.

Historical background

Applications for the Linux desktop have historically been developed with either Gtk+ or Qt, the two dominant open source widget toolkits. Qt was originally created by Trolltech, a commercial software vendor that offered the toolkit under a dual-licensing model. Linux distributors and major commercial vendors in the Linux ecosystem largely standardized around Gtk+ during the early days of the Linux desktop because its permissive licensing made it a less expensive choice for proprietary software vendors.

Although Gtk+ has many fine characteristics and has been used to develop a compelling body of sophisticated applications, it hasn't advanced as quickly as Qt and lags far behind on features and portability. After struggling for several years with the limitations of Gtk+, Nokia acquired Trolltech in 2008 with the aim of adopting Qt as the standard unifying development toolkit across its Symbian and Linux-based mobile platforms.

Nokia relicensed Qt under the LGPL in 2009, eliminating the commercial licensing barrier that had previously impeded broader adoption of the toolkit. In our coverage of the Qt licensing change, we predicted that the move could deflate ISV support for the GNOME ecosystem and lead to a shift towards Qt on the Linux desktop.

Indeed, Canonical's decision to include Qt in the default Ubuntu installation is an acknowledgement of the growing enthusiasm for the toolkit among third-party developers. Companies that already use Qt for cross-platform development include Google, Amazon, Skype, Adobe, and Angry Birds developer Rovio.

GNOME integration in Qt apps

Although Ubuntu is embracing Qt on the desktop, it will still be a GNOME-based distribution. Canonical is funding the development of Qt bindings for key GNOME frameworks so that Qt-based software on Ubuntu can integrate optimally with the GNOME desktop environment. As a starting point for this effort, Canonical contracted GNOME developer Ryan Lortie to develop Qt bindings for the dconf settings system.

Integration with dconf will allow Qt applications to more easily share settings with Gtk+ applications and will also enable features like configuration change monitoring, which is needed to support GNOME's instant-apply paradigm for settings.

Relationship with KDE and GNOME

The notion of GNOME-specific Qt applications has drawn some criticism from the KDE community. KDE developer Aaron Seigo wrote a blog post this morning experssing some concerns about the Qt dconf bindings. He highlighted the need for more collaboration and cross-desktop consensus on key plumbing issues in order to avoid too much fragmentation.

The Ubuntu and KDE developers recently collaborated constructively on cross-desktop standards for the notification area, but it's difficult to devise solutions that meet the needs of both environments. It's worth noting, for example, that the KDE community has historically been resistant to having a shared configuration system between the desktops.

Shuttleworth says that there is a relevant distinction between Qt applications and KDE applications. In order to be considered for inclusion in Ubuntu, a Qt-based application would have to conform with the desktop's APIs and conventions. This means that conventional KDE applications—which come with heavy KDE infrastructure dependencies and have KDE-centric behaviors—will likely not be coming to the standard Ubuntu installation any time in the near future.

Ubuntu's move to accept Qt applications will likely put some pressure on the distribution's relationship with the GNOME community, which is already somewhat strained. Canonical's decision to use Ubuntu's own custom Unity shell instead of the new GNOME 3 shell generated significant controversy at the last Ubuntu Developer Summit. It's worth noting, however, that other distributions have taken similar steps. The MeeGo project also has a non-standard shell for its GNOME environment and similarly offers third-party developers the option of using Qt.

Shuttleworth emphasized in his statement this morning that support for Qt in Ubuntu shouldn't be viewed as an attack on GNOME. Ubuntu's developers are still aligned with GNOME's values and will continue to work with the GNOME community.

"The decision to be open to Qt is in no way a criticism of GNOME. It's a celebration of free software's diversity and complexity. Those values of ease of use and integration remain shared values with GNOME, and a great basis for collaboration with GNOME developers and project members," he wrote. "Perhaps GNOME itself will embrace Qt, perhaps not, but if it does then our willingness to blaze this trail would be a contribution in leadership.

Qt and Unity

Canonical recently published a special, Qt-based version of its Unity shell, but intends to continue using its current Compiz-based implementation for the standard installation. The Qt-based version is intended to be used as a fallback for hardware environments that can't do accelerated rendering or 3D visual effects.

The growing number of Unity frontends seems to be generating a lot of confusion. It's important to understand that most of the heavy lifting in Unity is being done by a set of generic shell and dock frameworks developed by Canonical that are loosely coupled with the Unity presentation layer. The same underlying components are used consistently across all of the Unity implementations, which means that the various flavors of Unity aren't from-scratch rewrites.

The development of a Qt front-end for Unity is largely unrelated with Ubuntu's decision to support Qt in the default installation. For a clearer picture of the role that the Qt-based Unity will play in Ubuntu, I recommend reading the recent coverage of the matter that was published by Linux Pro Magazine.

A major win

As a third-party Linux application developer myself, I think that Canonical's support for Qt is a major win for Ubuntu users and developers. Qt has gained a lot of extremely powerful capabilities that accelerate application development and allow developers and designers to create richer and more expressive user interfaces.

Although I think that Qt has a lot to offer on Ubuntu, there is still a lot of work that needs to be done to make it possible for Qt applications to integrate optimally with the GNOME desktop. There are still many other integration points besides the configuration system that need to be exposed to Qt.

It's also critically important to ensure that tight desktop integration won't break cross-platform compatibility or require a lot of platform-specific code paths. In trivial use cases where platform-specific features aren't required, Qt should just natively do the right thing. For example, it would be beneficial if developers could simply rely on Qt's QSettings class to support basic dconf storage rather than having to use a separate library (though a separate library would still be needed for change notification and other features that aren't in the QSettings scope).

In light of the important role that Qt applications will play in the GNOME-centric MeeGo netbook environment, improvements that aim to make Qt integration with GNOME more seamless will also benefit MeeGo in addition to Ubuntu. It seems like Nokia has a few obvious incentives to collaborate with Canonical in order to continue improving Qt's GNOME integration. Some great progress has already been made on that front over the past few years, particularly with theming consistency improvements.

If Nokia, Canonical, and the Ubuntu developer community can work together to facilitate really tight integration between Qt and GNOME, we could see Qt gain a lot more ground on the Linux desktop.