GTK+是C语言的绑定,C语言做面向对象工程实在太繁琐了。
而C++语言绑定的GTKmm,尽管它们不断地吹嘘自己对C语言标准如何遵守,如何如何“纯粹”,但是C++开发的首选还是Qt的,Qt的易用性和成功案例远超过gtkmm。
QML是Qt新引进的简单编程语言,类似于Javascript的感觉,不过QML的速度是很快的,目前用于KDE 4.8的plasmoid(Widget)以及开发触摸屏设备的应用程序是最适合的。
Unity-2D是用Qt开发的,所以Ubuntu未来用Qt开发软件中心的目的可能是为了在Unity和Unity-2D下能有更加统一的外观(当然,个人感觉这是原因之一)。
--以上为个人猜测。
这是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.pdf2.
Qt apps on Ubuntu Mark Shuttleworth3.
GTK vs Qt - WikiVS4.
http:// dot.kde.org/2003/03/31/ george-staikos-quick-cost-analysis-qt-vs-gtk5.
App ecosystem6.
The Qt 5 Open Source Project on Ohloh7.
The GTK+ Open Source Project on Ohloh8.
ubuntu touch9.
GTK+/RoadmapQT写界面跟用HTML差不多,而且QT包装如此好,即有JAVA与C#那样畅快的体验,有没有太多的负担,跨平台几乎无缝,不用它反而是奇怪的事。