Why is Canonical choosing QT over GTK for Unity's next generation?

You can find the answer on the mailing list and on Mark Shuttleworth's blog. This blog post probably answers it best:

As part of our planning for Natty+1, we’ll need to find some space on the CD for Qt libraries, and we will evaluate applications developed with Qt for inclusion on the CD and default install of Ubuntu.

Ease of use, and effective integration, are key values in our user experience. We care that the applications we choose are harmonious with one another and the system as a whole. Historically, that has meant that we’ve given very strong preference to applications written using Gtk, because a certain amount of harmony comes by default from the use of the same developer toolkit. That said, with OpenOffice and Firefox having been there from the start, Gtk is clearly not an absolute requirement. What I’m arguing now is that it’s the values which are important, and the toolkit is only a means to that end. We should evaluate apps on the basis of how well they meet the requirement, not prejudice them on the basis of technical choices made by the developer.

In evaluating an app for the Ubuntu default install, we should ask:

• is it free software?
• is it best-in-class?
• does it integrate with the system settings and preferences?
• does it integrate with other applications?
• is it accessible to people who cannot use a mouse, or keyboard?
• does it look and feel consistent with the rest of the system?

Of course, the developer’s choice of Qt has no influence on the first two. Qt itself has been available under the GPL for a long time, and more recently became available under the LGPL. And there’s plenty of best-in-class software written with Qt, it’s a very capable toolkit.

System settings and prefs, however, have long been a cause of friction between Qt and Gtk. Integration with system settings and preferences is critical to the sense of an application “belonging” on the system. It affects the ability to manage that application using the same tools one uses to manage all the other applications, and the sorts of settings-and-preference experience that users can have with the app. This has traditionally been a problem with Qt / KDE applications on Ubuntu, because Gtk apps all use a centrally-manageable preferences store, and KDE apps do things differently.

To address this, Canonical is driving the development of dconf bindings for Qt, so that it is possible to write a Qt app that uses the same settings framework as everything else in Ubuntu. We’ve contracted with Ryan Lortie, who obviously knows dconf very well, and he’ll work with some folks at Canonical who have been using Qt for custom development work for customers. We’re confident the result will be natural for Qt developers, and a complete expression of dconf’s semantics and style.

The Qt team have long worked well in the broader Ubuntu community – we have great Qt representation at UDS every six months, the Kubuntu team have deep experience and interest in Qt packaging and maintenance, there is lots of good technical exchange between Qt upstream and various parts of the Ubuntu community, including Canonical. For example, Qt folks are working to integrate uTouch.

I’d draw a distinction between “Qt” and “KDE” in the obvious places. A KDE app doesn’t know anything about the dconf system configuration, and can’t easily integrate with the Ubuntu desktop as a result. So we’re not going to be proposing Amarok to replace Banshee any time soon! But I think it’s entirely plausible that dconf, once it has great Qt bindings, be considered by the KDE community. There are better people to lead that conversation if they want, so I’ll not push the idea further here . Nevertheless, should a KDE app learn to talk dconf in addition to the standard KDE mechanisms, which should be straightforward, it would be a candidate for the Ubuntu default install.

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. 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. It’s much easier to make a vibrant ecosystem if you accept a certain amount of divergence from the canonical way, so to speak Our work on design is centered around GNOME, with settings and preferences the current focus as we move to GNOME 3.0 and gtk3.

Of course, this is a perfect opportunity for those who would poke fun at that relationship to do so, but in my view what matters most is the solid relationship we have with people who actually write applications under the GNOME banner. We want to be the very best way to make the hard work of those free software developers matter, by which we mean, the best way to ensure it makes a real difference in millions of lives every day, and the best way to connect them to their users.

To the good folks at Trolltech, now Nokia, who have made Qt a great toolkit – thank you. To developers who wish to use it and be part of the Ubuntu experience – welcome.

GTK+ does not support resolution independence, Modern mobile devices have ultra high pixel densities. If you run a GTK+ application on a mobile screen all the user interface elements would be so small as to be unusable.

This has been an open bug on GTK+ since 2008 till it was closed in 2014 with "we have hi-dpi scale support now - it is not quite the same thing, but close enough to render this bug obsolete" comment.

When GTK+3 was released, the project had the perfect opportunity to add resolution independence, because they were breaking compatibility anyway. They chose not to, and now it is really too late for them.

On the GTK+ Roadmap, resolution independence is planned for the release after 4.0, so they will release 4.0 then the major release after that will have it. If they stick to that plan then even desktop GNU/Linux will have to abandon GTK+ because high DPI desktop monitors and laptop monitors are available already and are about to become the new normal.

My take on the Technical/pragmatic reasons: Nokia purchased Trolltech and invested a lot into QT. Its lightweight and has years of optimization toward mobile platform. Regardless of your current opinions of Nokia, the N900 was years ahead of its time ... and it was debian / QT based... but pricey. However, I have no real knowledge of the decisions.

Ubuntu CTO Matt Zimmerman's blog is also informative:

It is in this spirit that I have been thinking about Qt recently. We want to make it fast, easy and painless to develop applications for Ubuntu, and Qt is an option worth exploring for application developers. In thinking about this, I’ve realized that there is quite a bit of commonality between the strengths of Qt and some of the new directions in Ubuntu:

• Qt has a long history of use on ARM as well as x86, by virtue of being popular on embedded devices. Consumer products have been built using Qt on ARM for over 10 years. We’ve been making Ubuntu products available for ARM for nearly two years now, and 10.10 supports more ARM boards than ever, including reference boards from Freescale, Marvell and TI. Qt is adding ARMv7 optimizations to benefit the latest ARM chips. We do this in order to offer OEMs a choice of hardware, without sacrificing software choice. Qt preserves this same choice for application developers.
• Qt is a cross-platform application framework, with official ports for Windows, MacOS and more, and experimental community ports to Android, the iPhone and WebOS. Strong cross-platform support was one of the original principles of Qt, and it shows in the maturity of the official ports. With Ubuntu Light being installed on computers with Windows, and Ubuntu One landing on Android and the iPhone, we need interoperability with other platforms. There is also a large population of developers who already know how to target Windows, who can reach Ubuntu users as well by choosing Qt.
• Qt has a fairly mature touch input system, which now has support for multi-touch and gestures (including QML), though it’s only complete on Windows 7 and Mac OS X 10.6. Meanwhile, Canonical has been working with the community to develop a low-level multi-touch framework for Linux and X11, for the benefit of Qt and other toolkits. These efforts will eventually meet in the middle.

Overall, I think Qt has a lot to offer people who want to develop applications for (and on) Ubuntu, particularly now. It already powers popular cross-platform applications like VLC, not to mention the entire Kubuntu distribution. I missed it when this happened last year, but Qt is now available under either the LGPL 2.1 or the GPL 3.0, which should make it suitable for virtually any Ubuntu application. It has strong commercial backing as well as a large developer community. No single solution will meet all developers’ needs, of course, and Ubuntu supports multiple toolkits and frameworks for this reason, but Qt seems like a great tool to have in our toolbox for the road ahead.

An Ars Technica article discussing this blog post provides some insights:

Qt can bring third-party developers to Linux

Although Gtk+ still has value and there are a number of reasons to continue using it for building native Linux software, Qt is now the obvious choice for ISVs that are targeting multiple platforms. Qt makes it exceptionally easy to conform to the native look and feel of the underlying platform or build a totally custom user interface that is optimally suited to a target device or form factor.

As Nokia and Intel bring MeeGo to a wide range of devices, it's going to attract some major commercial software vendors. It would be relatively easy for those software companies to bring their mobile Qt applications to the Linux desktop using the same code that they use on MeeGo. Qt is specifically designed to make that easy. This would be a huge win for desktop Linux because it would bring third-party applications that would not otherwise be available.

It's worth noting that some prominent mobile software vendors are already eagerly embracing Qt due to Nokia's support for the toolkit. Mobile video streaming company Qik, for example, is working on an experimental Qt-based port of its popular application with the aim of bringing it to MeeGo.

The author of the article is the creator of the Gwibber IM app, so he has some experience developing GUIs for Linux.