Answers:
您可以在邮件列表和Mark Shuttleworth的博客上找到答案。这篇博客文章可能是最好的答案：
作为我们对Natty + 1计划的一部分，我们需要在CD上找到一些Qt库的空间，并且我们将评估使用Qt开发的应用程序是否包含在CD中以及Ubuntu的默认安装中。
易于使用和有效集成是我们用户体验中的关键价值。我们关心我们选择的应用程序彼此之间以及整个系统之间的和谐。从历史上看，这意味着我们非常倾向于使用Gtk编写的应用程序，因为默认情况下，使用同一开发人员工具包会产生一定程度的协调。就是说，OpenOffice和Firefox从一开始就存在，Gtk显然不是绝对必要。我现在要争论的是重要的是价值观，而工具包只是达到此目的的一种手段。我们应该根据应用程序满足要求的程度来评估应用程序，而不是根据开发人员的技术选择来损害它们。
在评估Ubuntu默认安装的应用程序时，我们应该询问：
- 它是免费软件吗？
- 它是一流的吗？
- 它与系统设置和首选项集成吗？
- 它可以与其他应用程序集成吗？
- 不能使用鼠标或键盘的人可以使用它吗？
- 它的外观和感觉是否与系统的其余部分一致？
当然，开发人员选择Qt不会影响前两个。Qt本身在GPL下已经存在了很长时间，最近又在LGPL下可用。还有很多用Qt编写的一流软件，这是一个功能强大的工具箱。
然而，系统设置和偏好长期以来一直是Qt与Gtk之间冲突的原因。与系统设置和首选项的集成对于感觉应用程序在系统上“属于”至关重要。它会影响使用与其他所有应用程序相同的工具来管理该应用程序的能力，以及用户使用该应用程序所具有的各种设置和首选项体验。传统上，这是Ubuntu上Qt / KDE应用程序的问题，因为Gtk应用程序均使用可集中管理的首选项存储，而KDE应用程序的处理方式有所不同。
为了解决这个问题，Canonical正在推动针对Qt的dconf绑定的开发，以便有可能编写使用与Ubuntu中其他所有东西相同的设置框架的Qt应用。我们已经与Ryan Lortie签约，后者显然非常了解dconf，他将与Canonical的一些人员合作，这些人员一直在使用Qt为客户进行自定义开发工作。我们相信结果对于Qt开发人员将是自然的，并且是dconf语义和样式的完整表达。
Qt团队在更广泛的Ubuntu社区中长期运作良好–我们每六个月都会在UDS上有出色的Qt代表，Kubuntu团队在Qt打包和维护方面拥有丰富的经验和兴趣，Qt上游与各种Qt之间有很多良好的技术交流Ubuntu社区的一部分，包括Canonical。例如，Qt人员正在努力集成uTouch。
在明显的地方，我会区分“ Qt”和“ KDE”。KDE应用程序对dconf系统配置一无所知，因此无法轻松地与Ubuntu桌面集成。因此，我们不会在短期内建议Amarok取代Banshee！但是我认为dconf一旦具有强大的Qt绑定，就应该由KDE社区考虑是完全合理的。如果他们愿意的话，可以有更好的人来领导对话，所以我在这里不再赘述。尽管如此，如果除了标准的KDE机制（这应该很简单）之外，KDE应用程序还要学习谈论dconf，它将是Ubuntu默认安装的候选对象。
向Qt开放的决定绝不是对GNOME的批评。这是对自由软件的多样性和复杂性的庆祝。这些易用性和集成性价值仍然是GNOME的共同价值，也是与GNOME开发人员和项目成员进行协作的良好基础。也许GNOME本身会接受Qt，也许不会，但是如果这样做的话，我们愿意走这条路将是对领导力的贡献。如果您接受规范的方式有一定程度的差异，那么创建一个充满活力的生态系统就容易得多，可以这么说。我们的设计工作围绕GNOME进行，随着我们转向GNOME 3.0和gtk3，当前的重点是设置和首选项。
当然，对于那些会嘲笑这种关系的人来说，这是一个绝好的机会，但是我认为最重要的是我们与实际在GNOME旗帜下编写应用程序的人之间的牢固关系。我们希望成为使这些自由软件开发人员的辛勤工作变得重要的最佳方法，也就是说，确保每天在数百万人的生活中产生真正改变的最佳方法，以及将他们与他人联系起来的最佳方法。他们的用户。
对于Trolltech的好朋友，现在是诺基亚，已经使Qt成为了一个很好的工具包–谢谢。对于希望使用它并成为Ubuntu经验一部分的开发人员–欢迎。
GTK +不支持分辨率独立性，现代移动设备具有超高像素密度。如果您在移动屏幕上运行GTK +应用程序，则所有用户界面元素都将非常小而无法使用。
自2008年以来，这一直是GTK +上的一个开放式错误，直到2014年关闭时为止，“我们现在提供了高dpi缩放比例支持-这不是完全相同的事情，但是足够接近，足以使此错误过时”注释。
当GTK + 3发布时，该项目有了增加分辨率独立性的绝好机会，因为它们反正破坏了兼容性。他们选择不这样做，现在对他们来说真的为时已晚。
在GTK +路线图上，计划在4.0之后的版本中解决分辨率独立问题，因此他们将发布4.0，然后再发布主要版本。如果他们坚持这一计划，那么甚至台式机GNU / Linux也将不得不放弃GTK +，因为高DPI台式机显示器和笔记本电脑显示器已经可用，并且将成为新的常态。
我的技术/实用理由是：诺基亚购买了Trolltech，并在QT上投入了大量资金。它轻巧，并针对移动平台进行了多年的优化。不管您对诺基亚当前的看法如何，N900都比其时代早了几年……而且它是基于debian / QT的……但价格昂贵。但是，我对决策并不了解。
Ubuntu CTO Matt Zimmerman的博客也提供了很多信息：
正是本着这种精神，我最近一直在思考Qt。我们希望能够快速，轻松且轻松地为Ubuntu开发应用程序，而Qt是值得应用程序开发人员探索的选择。考虑到这一点，我意识到Qt的优势与Ubuntu中的一些新方向之间存在很多共性：
- 由于在嵌入式设备上很受欢迎，Qt在ARM和x86上都有悠久的使用历史。消费产品已经在ARM上使用Qt构建了10多年。我们已经将Ubuntu产品用于ARM已有近两年了，并且10.10支持比以往任何时候都更多的ARM板，包括Freescale，Marvell和TI的参考板。Qt正在添加ARMv7优化，以使最新的ARM芯片受益。我们这样做是为了在不牺牲软件选择的情况下为OEM提供硬件选择。Qt为应用程序开发人员保留了相同的选择。
- Qt是一个跨平台的应用程序框架，具有用于Windows，MacOS等的正式端口，以及用于Android，iPhone和WebOS的实验性社区端口。强大的跨平台支持是Qt的原始原则之一，它在官方端口的成熟中显示。随着装有Windows的计算机上安装了Ubuntu Light，并在Android和iPhone上安装了Ubuntu One，我们需要与其他平台的互操作性。还有大量的开发人员已经知道如何针对Windows，他们也可以通过选择Qt来吸引Ubuntu用户。
- Qt具有相当成熟的触摸输入系统，尽管仅在Windows 7和Mac OS X 10.6上才完整，但它现在已支持多点触摸和手势（包括QML）。同时，Canonical一直在与社区合作，为Qt和其他工具包的利益开发用于Linux和X11的低级多点触控框架。这些努力最终将在中间达成。
总的来说，我认为Qt可以为想为Ubuntu（以及在Ubuntu上）开发应用程序的人们提供很多东西。它已经为VLC等流行的跨平台应用程序提供了支持，更不用说整个Kubuntu发行了。去年发生这种情况时，我很想念它，但是Qt现在可以在LGPL 2.1或GPL 3.0下使用，这实际上使其适用于任何Ubuntu应用程序。它具有强大的商业支持以及庞大的开发者社区。当然，没有任何一种解决方案可以满足所有开发人员的需求，因此，Ubuntu支持多种工具包和框架，但是Qt似乎是我们工具箱中适用于未来发展的好工具。
讨论此博客文章的Ars Technica文章提供了一些见解：
Qt可以将第三方开发人员引入Linux
尽管Gtk +仍然具有价值，并且出于多种原因可以继续使用它来构建本机Linux软件，但是Qt现在是针对多个平台的ISV的明显选择。通过Qt，可以非常轻松地符合底层平台的本机外观或建立完全自定义的用户界面，该界面最适合目标设备或外形尺寸。
随着诺基亚和英特尔将MeeGo带入各种设备中，它将吸引一些主要的商业软件供应商。对于那些软件公司而言，使用在MeeGo上使用的相同代码将其移动Qt应用程序带到Linux桌面将相对容易。Qt是专门设计用来简化这一过程的。对于桌面Linux来说，这将是一个巨大的胜利，因为它将带来第三方应用程序，否则这些应用程序将无法获得。
值得注意的是，由于诺基亚对工具包的支持，一些著名的移动软件供应商已经急切地欢迎Qt。例如，移动视频流媒体公司Qik正在研究其受欢迎的应用程序基于Qt的实验端口，旨在将其引入MeeGo。
本文的作者是Gwibber IM应用程序的创建者，因此他在为Linux开发GUI方面具有一定的经验。