是什么让 Ubuntu 选用 Qt 而不是 GTK？

是什么让 Ubuntu 选用 Qt 而不是 GTK？

一个正在发生的事实，Ubuntu正在不断Qt化！
我曾一直在抱怨的Software Center，
今日一看源码，竟然有softwarecenter/ui/qml的分支，
虽然跑起来还挺难看的样子，但是可以想像未来是肯定要取代GTK版本了

-------------------------------------------------------------------------------------

这是Mark Shuttleworth下的一盘大棋....

两年前，Mark Shuttleworth 宣布Ubuntu要支持Qt程序，给出的理由是软件的易用性和方便集成的能力，是提供最终用户体验的关键价值所在。Ubuntu不是因为Gtk多么"纯粹", 多么牛B，多么性感才被选中的，Ubuntu选择的是像OpenOffice, Firefox这样体验上佳的软件，软件的技术框架只是附加选择。当初之所以选择Gnome是因为在当时条件下, Gnome桌面和其软件家族，在功能和系统体验的一致性上很好，而GTK被选择，则仅仅是Gnome使用了GTK，如此而已。

然后Mark给出选择软件框架的几个要求和Qt入选的理由：
* is it free software? Qt支持商业, GPL和LGPL三种授权，特别是LGPL称为决定性的胜出因素
* is it best-in-class? Qt在软件质量，功能，API设计，文档等方面广受赞誉
* does it integrate with the system settings and preferences? 当时Qt在这方面还稍有欠缺，为此Canonical决定赞助dconf - GNOME Wiki!这样的软件集成进Qt, 结果就是dconf-qt in Launchpad
* does it integrate with other applications? 原文未说明，不过这对Qt程序没什么问题，现在Qt和GTK基本上都统一到了D-BUS作为应用交互的系统总线了
* is it accessible to people who cannot use a mouse, or keyboard? Qt给出的答案是QtQuick QML
* does it look and feel consistent with the rest of the system? Qt Style， QML表示没有压力

那么，选择Qt是否意味着Ubuntu要亲近KDE而疏远GNOME了呢？
Mark对前者给予斩钉截铁地回答：No。 并且用整整一个段落来斩断这种遐想，表面上给出的理由是，KDE并没有集成像dconf-qt这样的软件包，而Ubuntu也无法或不想一个个去说服KDE的程序去集成进Ubuntu。而骨子里，其实Mark就是看不上KDE，随后不久, Canonical宣布解雇全职开发Kunbutu唯一的一个雇员，然后Kunbutu被迫变为完全社区驱动的发行版就是一个很明显的注解。

那么，看不上KDE这小三是不是就是因为爱GNOME这大老婆爱得深沉呢？ 是才怪！虽然为了安抚GNOME社区，Mark用了另一个整段来说明选择Qt不等于弃GNOME，当然了，一起生活了这么久，即使一下子想休也不是那么容易休掉的，要慢慢来嘛！ GNOME、GTK推3.x, 咱先不跟了，Gnome shell再慢慢用Unity换掉，嗯，X11, Wayland都不合口味，也扔掉，上Mir.... 哇，这下有点玩大了，釜底抽薪靠什么支持上面的应用, 这是就需要Qt登场了，有了锤炼了好几年的QPA系统抽象层，换底层架构就方便多了。

有了这些铺垫，今年初当Canonical宣布她的Ubuntu Phone OS就水到渠成了，被选择的，既不是GTK和GNOME，更加不是KDE，而是最为一个跨越桌面，平板和手持设备的整体系统解决方案的Qt框架，如果你曾经开发过Symbian，MeeGo的Qt程序，当你打开Ubuntu Phone OS的SDK时，你会觉得非常熟悉，没错，Canonical原封不动地把Qt Mobility, QtQuick和Qt其它基础模块一股脑地接了过来。Qt将成为Ubuntu未来地官方API， QML则是跨桌面，平板，手机的原生UI解决方案。

这是从Ubuntu的发展和Canonical公司的战略角度来看Qt被选择的背后动机， 如果单纯的比较GTK和Qt的话，Qt在以下方面是胜出的（当然不是各个方面都是Qt好，GTK也有自己的优势）：
1. 灵活的许可证
要说这是最核心的，狗血的是，Qt当初不灵活的QPL许可证也是催生GNOME/GTK的最大原因，然而此一时彼一时，Qt一直在进步，先是商业+GPL, 后被Nokia加上LGPL， 已经成了最开放的开源项目之一，无论你是开源，闭源和商业开发者，都可以放心使用Qt。GTK是LGPL，可以被闭源程序使用，但是没有真正的商业License，基本上除了雇程序员自给自足，找不到地方花钱买服务，这对很多项目其实很关键。

2. 社区活跃度
Qt核心活跃开发者基本上是GTK的4+倍, 代码commits是GTK的5+倍 (2011年数据），随着Nokia弃用Qt，2012-2013的统计有所下降，不过还是比GTK高一个数量级，大家可以看Ohloh的详细统计数据

3.性能
其实传统的Qt Widgets和GTK相比，性能上彼此彼此。不过QtQuick出现以后，Qt开始甩开GTK好几条街，更确切的说，GTK社区没有拿出相对应的解决方案。

4. 分辨率无关开发
QtQuick/QML对现代的移动，嵌入式触摸设备的GUI开发是必不可少的。现在的显示设备的另一个特点是，像素密度很大，而且不同设备像素密度差异也很大，即使是桌面平台，随着retina的出现，也开始了DPI竞赛。而GTK+不支持“分辨率无关”开发，这样GTK写出来的程序，在现在的智能手机上看起来就像屎堆上的一对苍蝇... 当然Qt Widgets写出来的也是一样，这就体现出了QtQuick的优势来。而据说，GTK+对此的计划是... GTK4.x再提供支持...... 这样以来，估计用不了多久，连GTK桌面程序看起来也只能是渣渣了。

5. 可移植性
这也是Qt的王牌之一， 除了三大桌面外，Qt还支持几乎所有主流智能手机操作系统（让我们略过Windows Phone...）, 刚刚发布的Qt 5.1已经尝试支持Android和iOS平台，Qt 5.2将正式支持Android和iOS, 加上本就支持的Symbian(dead), MeeGo(dead), Tizen, WebOS, BlackBerry/QNX, VxWorks, Ubuntu Phone OS, Sailfish OS。而GTK只能勉强支持三大桌面(Linux/Unix基本上只能X11, Framebuffer支持有限，EglFS完全不支持）。

6. 其它
qt-creator 已经渐渐地称为了VS之外的最佳C/C++ IDE, Qt还有开源社区非常少见的优美丰富的文档，Qt框架覆盖广泛，不仅仅限于GUI，就这点来说拿Qt和GTK比，其实有点委屈了Qt。

参考：
1. http://www.cs.uta.fi/~TKOPS407/sd-seminar-25-2-2009.pdf
2. Qt apps on UbuntuMark Shuttleworth
3. GTK vs Qt - WikiVS
4. http://dot.kde.org/2003/03/31/george-staikos-quick-cost-analysis-qt-vs-gtk
5. App ecosystem
6. The Qt 5 Open Source Project on Ohloh
7. The GTK+ Open Source Project on Ohloh
8. ubuntu touch
9. GTK+/Roadmap

 

参考：http://www.zhihu.com/question/20153991