选择 Qt Widgets 还是 QtQuickControls?

原文地址:http://blog.davidedmundson.co.uk/node/72

原文作者致力于将 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 的迁移应该是渐进的,避免任何后退。
  • 不要为了迁移而迁移。

6 Comments

  1. 寒山居士 2014年4月14日
    • 豆子 2014年4月14日
      • 寒山居士 2014年4月17日
  2. Hello 2014年4月30日
  3. fengyi 2014年7月22日
    • 豆子 2014年7月25日

Leave a Reply