【发布时间】：2014-02-12 01:09:47
【问题描述】：
我心中有一个项目，想接手它，并选择 QT 作为开始时的首选框架。我一直在试图弄清楚如何启动并安装 Qt 包（SDK 和 Qt Creator）。问题是 - 我无法弄清楚 Qt Quick 和 Qt Widgets 的确切用例。我计划使用以下属性使该项目具有长期目的：
- 它将是一个仅限桌面 GUI 应用程序。如果我想制作一个移动版本，我会在原生或 HTML5 的移动平台上做，而不是 Qt。所以与任何移动平台的代码库兼容性不是我关心的。
- 触摸 UI 和动画也不属于功能集。但是，对创建图形的支持会很棒（我总是可以使用 QtWebkit 和 JS 来创建一些图形）
- Windows 是主要目标。目标用户可能不会使用 Linux 和 Mac。
- 它必须是可自行升级的 - 现在在做出选择时这不是什么大问题，但如果两者都有问题，一些知识会对我有所帮助。我不介意下载完整的应用程序安装程序，但独立更新模块会更好一些
- 它需要与 Web 服务器通信 以获取和上传数据（我认为 HTTP 将是 Qt 核心的工作，但我对 Qt 知之甚少）。
- 该应用需要具有内嵌编辑功能的表格、小型图片库、菜单、多部分窗口、拖放支持等。我找不到与 Qt Quick 相关的菜单。
考虑到该用例，什么是更好的选择 - Qt Widgets 或 Qt Quick？
关于我的一些信息以及我选择 Qt 的原因 - 我已经与 C++ 脱节将近 2 年了，并且在 Qt 中没有做任何严肃的事情，但 Qt 是一个比 Java 更可取的选择（后者我不太喜欢）。同样，我缺乏使用 Python 的经验。除了那个 Python UI 很烂，如果我必须为一个好的 UI 安装 QT 框架，为什么不在 Qt 中制作整个东西（考虑到我对 C++ 没问题）。所以 Qt 是我的首选。由于该项目需要跨平台兼容，所以 Qt 对我来说更有吸引力。
【问题讨论】：
-
如果你想要一个经典的、以桌面为主题的 UI，我现在会选择小部件。 QtQuick 控件正在向桌面 UI 发展，但在便利性和功能集与小部件匹配之前还需要一段时间。不过，请看一下 QtQuick 以及 C++ 如何与 QML 交互。如果您将所有业务逻辑保留在 C++ 中，并使 QtQuick 成为一个瘦 UI 层，那么它提供了一个干净的核心/UI 分离，如果您随后将小部件 UI 放在核心之上，这也是一个很好的做法。可以选择稍后切换到 QtQuick。
-
@FrankOsterfeld 我是一名 PHP 开发人员，有时必须处理“主题”。所以，是的，我得到了 C++ 中的逻辑背后的逻辑，并使 UI 成为一个薄层。但我是一个单身的人，将在这个项目上工作，我认为来年我不能为这个项目雇佣任何人（或几个）。所以代码库和开发都在我身上。我不想选择不稳定、无能或已弃用的东西。我不知道他们是否会退出 Widgets 以支持 Quick，因为 Widgets 的开发很少。
-
@VaibhavKaushal，不要担心小部件在未来会被弃用。太多的软件依赖于小部件，包括整个 KDE 桌面环境。在 Qt 开发人员日的一次演讲中，一位主要开发人员表示，由于用例不同，这两个框架都是作为替代开发的。例如，您需要 Qt Quick 的 3D 加速，这使得它几乎不可能在 VM 中使用。要考虑的另一点是，您将 QML 纯文本发送给可用于克隆您的软件的用户。
-
所以这意味着小部件将在那里，我应该使用小部件而不是 Qt Quick，因为我想要的一切都适合作为传统的桌面应用程序。正如下面提到的 Nicholas - 文档已经很好地开发并且可用于小部件。因此，我决定使用小部件。非常感谢你（Simon）、Frank 和 Nicholas :)
-
Qt Quick vs. Qt Widget 的可能重复项
标签： windows qt qtquick2 qtwidgets