为什么Canonical为Unity的下一代选择QT而不是GTK？
我写的很多，我有点困惑，但如果我没有错，Canonical正在用Qt为移动设备构建下一代Unity，并且在不久的将来桌面也将迁移到qt。
我只是想知道推动这一决定的技术和/或政治原因，以及它对当前现有的Ubuntu桌面应用程序意味着什么。
您可以在邮件列表和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旗下编写应用程序的人之间的稳固关系。 我们希望成为让这些自由软件开发人员努力工作的最佳方式，我们的意思是，确保它每天在数百万人的生活中发挥真正作用的最佳方式，以及将它们连接到他们的用户。
对于现在是诺基亚的奇趣科技公司的优秀人员，他们让Qt成为了一个很棒的工具包 – 谢谢。 对于希望使用它并成为Ubuntu体验一部分的开发人员 – 欢迎。
GTK +不支持分辨率独立性，现代移动设备具有超高像素密度。 如果您在移动屏幕上运行GTK +应用程序，则所有用户界面元素都会非常小而无法使用。
这是自2008年以来一直是GTK +上的一个漏洞，直到它在2014年关闭，“我们现在有高分辨率的支持 – 它不是完全相同的东西，但足够接近使这个bug过时”评论。
当GTK + 3发布时，该项目提供了增加分辨率独立性的绝佳机会，因为它们无论如何都破坏了兼容性。 他们选择不这样做，现在对他们来说真的太晚了。
在GTK +路线图上 ，计划在4.0之后发布解决方案独立性，因此它们将发布4.0然后主要版本将在此之后发布。 如果他们坚持这个计划，那么即使桌面GNU / Linux也不得不放弃GTK +，因为高DPI桌面显示器和笔记本电脑显示器已经可用并且即将成为新常态。
我对技术/实用理由的看法：诺基亚收购了奇趣科技，并在QT上投入了大量资金。 它轻巧，并且在移动平台上有多年的优化。 无论您目前对诺基亚的看法如何，N900都比它的时间提前了几年……它基于debian / QT ……但价格昂贵。 但是，我对这些决定并不了解。
Ubuntu首席技术官Matt Zimmerman的博客也提供了丰富的信息：
正是本着这种精神，我最近一直在思考Qt。 我们希望能够快速，轻松，轻松地为Ubuntu开发应用程序，Qt是一个值得为应用程序开发人员探索的选项。 考虑到这一点，我意识到Qt的优势与Ubuntu中的一些新方向之间有很多共性：
- 由于在嵌入式设备上很受欢迎，Qt在ARM和x86上的使用历史悠久。 使用Qt on ARM构建消费产品已超过10年。 我们已经为ARM提供了近两年的Ubuntu产品，10.10支持更多的ARM板，包括飞思卡尔，Marvell和TI的参考板。 Qt正在添加ARMv7优化以使最新的ARM芯片受益。 我们这样做是为了向OEM提供硬件选择，而不会牺牲软件选择。 Qt为应用程序开发人员保留了同样的选择。
- Qt是一个跨平台的应用程序框架，具有适用于Windows，MacOS等的官方端口，以及适用于Android，iPhone和WebOS的实验性社区端口。 强大的跨平台支持是Qt的原始原则之一，它显示了官方端口的成熟度。 随着Ubuntu Light安装在装有Windows的计算机上，Ubuntu One登陆Android和iPhone，我们需要与其他平台进行互操作。 还有大量开发人员已经知道如何定位Windows，他们也可以通过选择Qt来访问Ubuntu用户。
- Qt有一个相当成熟的触摸输入系统，现在支持多点触控和手势（包括QML），虽然它只在Windows 7和Mac OS X 10.6上完成。 同时，为了Qt和其他工具包的利益，Canonical一直与社区合作开发Linux和X11的低级多点触控框架。 这些努力最终将在中间相遇。
总的来说，我认为Qt可以为想要为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。 例如，移动video流媒体公司Qik正在研究其流行应用程序的基于Qt的实验端口，目的是将其引入MeeGo。
该文章的作者是Gwibber IM应用程序的创建者，因此他有一些为Linux开发GUI的经验。