选择 Qt Widgets 还是 QtQuickControls？

原文作者致力于将 QtQuickControls 运行在 KDE 环境。现在提出一个新的问题：在一个新的工程中，我们应该使用哪种技术？Qt Widgets 还是 QtQuickControls？

注意，本文并不是一个“信达雅”的翻译，而是基于原文的观点添加了很多“作料”。

或许这是每一个使用和学习 Qt 的朋友都很关心的问题。Qt Widgets 的历史悠久，组件丰富，不过是使用 C++ 开发，开发复杂效率慢；QtQuickControls 是最新发布的，基于 QtQuick，使用解释型的 QML 开发，开发简单效率高，缺点是目前组件不是很丰富。

基于上述原因，对于是不是使用 QtQuick 并没有一个直接的答案。事实上，这里也没有一个放之四海而皆准的答案。

有关 QtQuick 的几个传言 传言1：QWidgets 已死

事实上，自从 qtbase/widgets 模块从 4.x 代码库分离以来，至少已经有 2145 次提交（截止到2013年12月）。这充分表明 Qt 并没有放弃 Widgets，Widgets 依旧在发展和维护。

尽管每次 Qt 新版本发布，Widgets 都没有很大的改进（即便如此，我们也会注意到，几乎每次新版本发布都有有关 Widgets 的改进）。但是，这不是因为 Widgets 已经无人维护，而是因为在一定程度上，Widgets 已经成熟，没有很多所急需的改进。从开发者角度来说，这是一件好事，因为现在的 Widgets 已经不大可能发生大的激进的修改。

传言2：使用 QtQuick 编写代码更快

从灵活性的角度来看，创建富有艺术性的设计的确要简单很多。

不过，从传统的应用程序界面来看，使用 QtQuick 开发一个满屏都是下拉框、按钮和表单的界面也并不是那么容易。不要说现在的界面都在向着移动平台方向演化，真正企业级的应用界面的改进是很慢的。想想看现在有多少家企业仍在使用 Windows XP 就知道了。

对于初学者而言，Widgets 表单的布局可以使用 Qt Creator 拖画设计。因此，从 UI 文件加载、保存数据对于 Widgets 和 QtQuick 二者而言，其过程都是非常类似的。

在 KDE 框架中，很多重要的预构建组件要为大量任务提供支持。在 KDE 中，我们有预构建的选择插件的组件、选择全局快捷键的组件、输入密码的组件等等。如果我们要选择 QtQuick，那么这些组件都要重新编写，这肯定是一个非常痛苦并且缓慢的过程。

传言3：使用 QML 编写应用程序更好看

这是一个我反复听到的传言。事实上，QtQuick 只是一个工具，它不是魔法。

如果一个应用程序在 Widgets 中就存在设计问题，那么在 QML 中依然还是有问题的。

还有一点值得注意，创作自由度越高，越容易创造出看起来非常糟糕的界面。不一致的边框、过渡使用动画效果、由于组件缺少而不得不自己实现某些组件，这些都很容易把一个程序弄得比 Widgets 界面还要糟糕得多。

并不是每个看起来漂亮的界面都会有合适的效果。

传言4：QtQuickControls 和 QtWidgets 工作得一样好

在 KDE 的 Oxygen 主题下，我们使用 QtQuickControls 依然发现很多 bug。尽管我们正在修正这个错误，但是 Oxygen 是一个非常复杂的主题，很难把所有问题都解决。我们也将这些补丁发送给了上游。

另外，就像前面提到过的，QtQuickControls 缺少很多核心组件，比如树。

如果这篇文章写在半年之前，我可以肯定会有很大篇幅用来吐槽 QtQuick 的布局有多么糟糕、编写一个简单的标签页会有多么困难、移植那么多的 Widgets 组件会有多么复杂。

但是现在有了很好的改进，我们能够清清楚楚地看到 QtQuick 正在试图紧跟 Widgets 的步伐。

结论

毫无疑问，我相信未来是 QtQuick 和 QtQuickControls 的。问题是，这是“未来”。我们很难说这个“未来”是有多么的“未来”。

KDE 应用程序和工作台经常处于一种看不到头的 beta 测试状态，因为我们希望“下一个版本将会是完美的”。更改工具箱、重写应用程序无疑会占用大量有限资源，几乎任何重写都会在解决问题的同时引入新的问题。

QtQuick 和 QML 成功地解决了我们在 Widgets 中很难实现的自定义绘制的问题。

从表单布局方面看，Widgets 更强大，并且工作得很好。QtQuick 并不是一个并不存在的问题的解决方案（也就是说，既然用 Widgets 实现表单布局没有任何问题，那么 QtQuick 也不应该再去重造一个轮子，即 QtQuick 不应该尝试复制 Widgets 的全部内容）。

对于某些程序（比如 Plasma），QML 是最好的选择；对于另外一些程序，Widgets 则是最好的选择。

我乐于看到的 KDE 社区内应该是：

• 在技术选型之前，仔细分析你的项目的需求和目的。

• 在已有框架之上构建新的 QML 框架时，需要使用 QtQuick 开发出真正可用的早期原型。这种原型应该与现在的 Widgets 系统完全吻合。

• 对于已经项目（比如 KDE），向 QtQuick 的迁移应该是渐进的，避免任何后退。

• 不要为了迁移而迁移。