为什么 Canonical 为 Unity 的下一代选择 QT 而不是 GTK？

Question

写了这么多我有点困惑，但如果我没记错的话，Canonical 正在使用 Qt 为移动设备构建下一代 Unity，并且在不久的将来桌面也将迁移到 qt。

我只是想知道推动这个决定的技术和/或政治原因，以及它对当前现有的 Ubuntu 桌面应用程序意味着什么后果。

Answer 1

您可以在邮件列表和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 绑定，以便编写一个 Qt 应用程序，该应用程序使用与 Ubuntu 中的其他所有内容相同的设​​置框架。我们已经与 Ryan Lortie 签约，他显然非常了解 dconf，他将与 Canonical 的一些人一起工作，他们一直在使用 Qt 为客户进行定制开发工作。我们相信结果对于 Qt 开发人员来说是自然的，并且是 dconf 语义和风格的完整表达。

Qt 团队长期以来在更广泛的 Ubuntu 社区中工作得很好——我们每六个月在 UDS 上都有很好的 Qt 代表，Kubuntu 团队在 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 体验的一部分的开发人员 - 欢迎。

Answer 2

GTK+ 不支持分辨率独立，现代移动设备具有超高像素密度。如果您在移动屏幕上运行 GTK+ 应用程序，则所有用户界面元素都会小到无法使用。

自 2008 年以来，这一直是GTK+ 上的一个开放错误，直到 2014 年它被关闭，“我们现在有 hi-dpi 比例支持 - 这不是完全相同的事情，但足够接近使这个错误过时”评论。

当 GTK+3 发布时，该项目有一个绝佳的机会来添加分辨率独立性，因为无论如何它们都会破坏兼容性。他们选择不这样做，现在对他们来说真的太晚了。

在GTK+ Roadmap 上，计划在 4.0 之后发布分辨率独立性，因此他们将发布 4.0，然后主要版本将拥有它。如果他们坚持这个计划，那么即使是桌面 GNU/Linux 也将不得不放弃 GTK+，因为高 DPI 桌面显示器和笔记本电脑显示器已经可用并且即将成为新常态。