QT

来自：https://www.cnblogs.com/lsgxeva/p/7826761.html

http://www.cnblogs.com/Fuss/p/4350517.html

推荐：

https://blog.csdn.net/liang19890820/article/details/51752029

QML VS Qt Quick

从概念上区分

为了更精确地对两者进行说明，来看助手的描述：

QML is a user interface specification and programming language.

QML 是一种用户界面规范和标记语言，允许开发人员和设计师创建高性能、流畅的动画和视觉吸引人的应用程序。

有点意思，文档对 QML 的定义主要分为两点：

1. 用户界面规范：QML 提供了一种高度可读、声明性、类似 JSON 的语法，支持与动态属性绑定相结合的命令式 JavaScript 表达式。
2. 标记语言：像 C++ 一样，QML 是一种语言，文件格式以 .qml 结尾。

Qt Quick is the standard library of types and functionality for QML.

Qt Quick 是 QML 类型和功能的标准库，包括视觉类型、交互式类型、动画、模型和视图、粒子效果和着色效果。

Qt Quick 使用 QML 作为声明语言，来设计以用户界面为中心的应用程序。严格来讲，Qt Quick 是一个用于 QML 的工具包，允许以 QML 语言来开发图形界面。当然，还有其他的工具包用于 QML：

• 图形化的（例如：Sailfish Silica 或 BlackBerry Cascades）
• 非图形的（例如：QBS - QMake/CMake/make…的一个替代品）

从模块上区分

QML 由 Qt QML 模块提供，QtQuick QML 库由 Qt Quick 模块提供。

• Qt QML 模块：为 QML 应用程序提供了语言和引擎基础结构。
• Qt Quick 模块：提供了许多可视化组件、模型视图支持、动画框架以及用于构建用户界面的更多功能。

QtQuick 1.x VS QtQuick 2.x

QtQuick 主要包括：QtQuick 1.x 和 QtQuick 2.x，它们之间的区别主要涉及以下内容：

• 全新的 Qt 版本

  • QtQuick 1.x 基于 Qt4.x。
  • QtQuick 2.x 随 Qt5.0 一起引入。

• 全新的绘图系统

  • QtQuick 1.x 使用 QGraphicsView/QPainter API 来绘制场景。
  • QtQuick 2.x 基于 Scene Graph，一个 OpenGL（ES）2.0 抽象层，对绘图进行了高度优化，效率更高。

• 全新的 QML 引擎

  • Qt 4.x 中，QML 引擎基于JSC（JavaScriptCore - Webkit 的 JS 引擎）。
  • Qt 5.0 中引入 V8（Google 的开源高性能 JavaScript 引擎，用 C++ 编写，用于 Chromium、Node.js 和多个其他嵌入应用程序）。
  • Qt 5.2 中引入了 V4 JS 引擎，针对 QML 用例进行了优化，并且可以选择关闭 JIT（Just-In-Time）编译，以符合 iOS 和 WinRT 平台的限制。个头更小、反应更快、扩展性也非常好。

• 从 Qt 5.5 开始，加入了一个新模块 QtQuick3D，它提供使用 QML 语言创建 3D 应用程序/游戏的能力，其使用的是一个被命名为 FrameGraph 的新引擎，而非 Scene Graph（因为太 2D/2.4D）。

• 模块、属性和方法、类型和 API、C++ 代码（QtDeclarative 被移除了，替代的它是Qt QML 和 Qt Quick 模块）、QML 插件的更改。 
  ……

为什么要引入 QML/Qt Quick？

在我看来，主要归结为以下几点：

• 战略性发展

  Qt 想用 QML/Qt Quick 一统天下（桌面 ＋ 移动端）。梦想还是要有的，万一实现了呢？

  众所周知，Qt 为跨平台而生，而 QML/Qt Quick 作为 Qt 新生力量，完完全全继承了 Qt 包罗万象的特点，它的诞生为 Qt 进军移动领域迈出了历史性的一步。

  随着 Qt 的不断迭代，QML/Qt Quick 也可用于开发传统的桌面程序，而且效率越来越高，这样以来，便可以用 QML/Qt Quick 做任何你想做的事情。

  QML/QtQuick 作为 Qt 的绝对核心，特别是对于界面要求较高的开发者来说，其作用更为重要。

• 开发效率的提升

  传统上的 native UI 开发普遍使用 C++、C#、Objective-C 等语言。但近年来，本地应用使用 HTML5 + JS 也成为了一种趋势。一方面硬件资源越来越丰富，另一方面 Web 技术让 JS 的解析速度更快。

  除此之外，其中一部分功劳要归功于 Google，由于其开源了其 NB 的 JS 引擎，Node.js 加上一个前端框架也可以开发本地应用了。例如：Electron - 构建跨平台的桌面应用程序。

  QML/Qt Quick 和 Node.js 类似，也提供了一系列 JS 和 C++ 交互的接口，便于 JS 和 C++ 通信。

• UI 与逻辑分离

  尽管对于大多数情况而言，在编写应用程序时只需 QML 和 JavaScript，但在有些情况下需要计算密集型任务（例如：复杂图像处理、物理引擎），并且将需要处理器竭力提供所有可用性能。

  在这些情况下，QML 应用开发适合使用 C++ 来进行扩展，以便在后台执行资源密集型任务，而界面设计和一些简单逻辑（例如：按钮变色、换肤、变形等）都可以在 JS 中完成。这样避免了传统应用开发前端设计和后台逻辑混合的情况，让界面设计者专心设计界面成为了可能。

  由于 QML 是在 Qt 上构建的，因此其继承了 Qt 框架中的大部分功能，尤其是信号和槽机制以及元对象系统。使用 C++ 创建的数据可从 QML 直接访问，而 QML 对象也可从 C++ 代码进行访问。

Qt Widgets VS QML/Qt Quick

Qt 4.7 发布时，引入了 QML，用于移动开发，其全面支持触摸操作、流畅的动画效果等。但在 Qt 5 中，QML 已经不再局限于移动开发，也可用于开发传统的桌面程序。

很长时间里，我都在使用 Qt Widgets。当第一次尝试 QML 时，发现它太原始。但随着 Qt 5 的持续更新，QML 已经大大改善 - 添加了更多的功能、更好的性能以及更多的平台支持。话虽如此，但 QML/Qt Quick 仍在发展，随着版本的更新，也会变得越来越成熟。

• 相比之下，Qt Widgets 更“老”、更成熟，而 QML/Qt Quick 则更“新”、更“现代”。
• 无论如何，Qt Widgets 和 QML/Qt Quick 都可以在多个平台上使用（Windows、Linux、OS X…）。

对于传统的桌面程序来说，优先考虑使用 Qt Widgets，若要开发更“现代”的 UI 与高级应用，建议使用 Qt5.x + QML 2.x + QtQuick 2.x。

对于移动端开发来说，建议使用 QML，协同 JavaScript，简单快捷、渲染效果更佳、界面更炫酷。不建议使用 Qt Widgets，其显示效果、适应性都不好。

信号和槽主要用于组件之间的通信，类似于.net和java中的委托。

　　使用QObject::connect方法将信号与槽关联起来，然后信号的发起者发出信号，接受者中的槽函数就会执行。

　　比如connect(this,SIGNAL(start()),worker,SLOT(Start()))，将当前类中start信号关联到worker对象的Start函数，当我们调用emit this->start()时就发出信号，槽函数就会收到这个信号。

　　connect函数还有第五个参数，这个参数决定信号何时传给槽，这里提一下，不过本人目前一直使用的默认值。

　　Qt::AutoConnection，默认值自动连接，当信号发起者与槽函数执行者在同一线程时，就会使用Qt::DirectConnection，反之则使用Qt::QueuedConnection。

　　Qt::DirectConnection，直接相连，信号一发起槽函数立马执行，信号发起者与执行者在同一线程。

　　Qt::QueuedConnection，队列式，信号发起者与执行者不在同一个线程，信号发起时，槽函数会等待调度。

　　Qt::BlockingQueuedConnection，跟Qt::QueuedConnection一样，不同的是信号发起时存在互斥锁，要等待槽函数返回，这样如果槽函数与信号函数在同一个线程中就会发生死锁（也就是一直堵在锁的位置，没法进入槽函数）。

　　Qt::UniqueConnection，这个通过“或”跟上面的一起使用，表示同样的connection只能连接一次，好像没啥作用了，对象、信号、槽相同的connection多次连接会失败。

　　信号与槽要想断开连接，使用QObject::disconnect方法。

　　关于信号和槽的使用也就这么多，但是经常用，特别是在多线程里面，遇上槽函数没执行可能是连接写错了或是槽函数所在线程哪里堵住了（比如死循环之类的）。