Qt 学习之路 2 --- 读书笔记

一、文章来由

来自豆子老师非常好的一本Qt教程，但是只有网络版，所以用这个做笔记了，不动笔墨不读书嘛~~

二、读书笔记

1、Qt 学习之路 2（2）：Qt 简介

1.1 关于 Qt 的一站式解决

Qt 是一个著名的 C++ 应用程序框架。但并不只是一个 GUI 库，因为 Qt 十分庞大，并不仅仅是 GUI 组件。使用 Qt，在一定程度上你获得的是一个“一站式”的解决方案：不再需要研究 STL，不再需要 C++ 的，不再需要到处去找解析 XML、连接数据库、访问网络的各种第三方库，因为 Qt 自己内置了这些技术。

1.2 跨平台 GUI 的三种实现策略：

API 映射：

API 映射是说，界面库使用同一套 API，将其映射到不同的底层平台上面。大体相当于将不同平台的 API 提取公共部分。比如说，将Windows 平台上的按钮控件和 Mac OS 上的按钮组件都取名为 Button。当你使用 Button 时，如果在 Windows平台上，则编译成按钮控件；如果在 Mac OS上，则编译成按钮组件。这么做的好处是，所有组件都是原始平台自有的，外观和原生平台一致；缺点是，编写库代码的时候需要大量工作用于适配不同平台，并且，只能提取相同部分的API。比如 Mac OS 的文本框自带拼写检测，但是 Windows 上面没有，则不能提供该功能。这种策略的典型代表是wxWidgets。这也是一个标准的 C++ 库，和 Qt 一样庞大。它的语法看上去和 MFC 类似，有大量的宏。据说，一个 MFC程序员可以很容易的转换到 wxWidgets 上面来。

API 模拟：

前面提到，API 映射会“缺失”不同平台的特定功能，而 API 模拟则是解决这一问题。不同平台的有差异 API，将使用工具库自己的代码用于模拟出来。按照前面的例子，Mac OS 上的文本框有拼写检测，但是 Windows 的没有。那么，工具库自己提供一个拼写检测算法，让 Windows 的文本框也有相同的功能。API 模拟的典型代表是 wine —— 一个 Linux 上面的 Windows 模拟器。它将大部分 Win32 API 在 Linux 上面模拟了出来，让 Linux 可以通过 wine 运行 Windows 程序。由此可以看出，API 模拟最大优点是，应用程序无需重新编译，即可运行到特定平台上。另外一个例子是微软提供的 DirectX，这个开发库将屏蔽掉不同显卡硬件所提供的具体功能。使用这个库，你无需担心硬件之间的差异，如果有的显卡没有提供该种功能，SDK 会使用软件的方式加以实现。（关于举例，可以参考文末一段精彩的讨论。）

GUI 模拟：

任何平台都提供了图形绘制函数，例如画点、画线、画面等。有些工具库利用这些基本函数，在不同绘制出自己的组件，这就是 GUI 模拟。GUI 模拟的工作量无疑是很大的，因为需要使用最基本的绘图函数将所有组件画出来；并且这种绘制很难保证和原生组件一模一样。但是，这一代价带来的优势是，可以很方便的修改组件的外观——只要修改组件绘制函数即可。很多跨平台的 GUI 库都是使用的这种策略，例如 gtk+（这是一个 C 语言的图形界面库。使用 C 语言很优雅地实现了面向对象程序设计。不过，这也同样带来了一个问题——使用大量的类型转换的宏来模拟多态，并且它的函数名一般都比较长，使用下划线分割单词，看上去和 Linux 如出一辙。gtk+ 并不是模拟的原生界面，而有它自己的风格，所以有时候就会和操作系统的界面格格不入。），Swing 以及我们的 Qt。

2、Qt 学习之路 2（3）：Hello, world!

2.1 main函数简单解析

#include <QApplication>
#include <QLabel>

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    QLabel label("Hello, world");
    label.show();

    return app.exec();
}

讲解：

前两行是 C++ 的 include 语句，这里我们引入的是QApplication以及QLabel这两个类。main()函数中第一句是创建一个QApplication类的实例。对于 Qt 程序来说，main()函数一般以创建 application 对象（GUI 程序是QApplication，非 GUI 程序是QCoreApplication。QApplication实际上是QCoreApplication的子类。）开始，后面才是实际业务的代码。这个对象用于管理 Qt 程序的生命周期，开启事件循环，这一切都是必不可少的。在我们创建了QApplication对象之后，直接创建一个QLabel对象，构造函数赋值“Hello, world”，当然就是能够在QLabel上面显示这行文本。最后调用QLabel的show()函数将其显示出来。main()函数最后，调用app.exec()，开启事件循环。我们现在可以简单地将事件循环理解成一段无限循环。正因为如此，我们在栈上构建了QLabel对象，却能够一直显示在那里（试想，如果不是无限循环，main()函数立刻会退出，QLabel对象当然也就直接析构了）。

2.2 另一种hello world写法

可以将上面的程序改写成下面的代码吗？

#include <QApplication>
#include <QLabel>

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    QLabel *label = new QLabel("Hello, world");
    label->show();

    return app.exec();
}

答案是，不可以 建议这样做！

首先，按照标准 C++ 来看这段程序。这里存在着内存泄露。当exec()退出时（也就是事件循环结束的时候。窗口关闭，事件循环就会结束），label 是没办法 delete 的。这就造成了内存泄露。当然，由于程序结束，操作系统会负责回收内存，所以这个问题不会很严重。即便你这样修改了代码再运行，也不会有任何错误。

早期版本的 Qt 可能会有问题（详见本文最后带有删除线的部分，不过豆子也没有测试，只是看到有文章这样介绍），不过在新版本的 Qt 基本不存在问题。在新版本的 Qt 中，app.exec()的实现机制确定，当最后一个可视组件关闭之后，主事件循环（也就是app.exec()）才会退出，main()函数结束（此时会销毁app）。这意味着，所有可视元素已经都关闭了，也就不存在后文提到的，QPaintDevice没有QApplication实例这种情况。另外，如果你是显式关闭了QApplication实例，例如调用了qApp->quit()之类的函数，QApplication的最后一个动作将会是关闭所有窗口。所以，即便在这种情况下，也不会出现类这种问题。由于是在main()函数中，当main()函数结束时，操作系统会回收进程所占用的资源，相当于没有内存泄露。不过，这里有一个潜在的问题：操作系统只会粗暴地释放掉所占内存，并不会调用对象的析构函数（这与调用delete运算符是不同的），所以，很有可能有些资源占用不会被“正确”释放。事实上，在最新版的 Sailfish OS 上面就有这样的代码：

#include <QApplication>

int main(int argc, char *argv[])
{
    QScopedPointer<QApplication> app(new QApplication(argc, argv));
    QScopedPointer<QQuickView> view(new QQuickView);
    view->setSource("/path/to/main.qml");
    ...
    return app->exec();
}

这段代码不仅在堆上创建组件实例，更是把QApplication本身创建在了堆上。不过，注意，它使用了智能指针，因此我们不需要考虑操作系统直接释放内存导致的资源占用的问题。

当然，允许使用并不一定意味着我们建议这样使用。毕竟，这是种不好的用法（就像我们不推荐利用异常控制业务逻辑一样），因为存在内存泄露。而且对程序维护者也是不好的。所以，我们还是推荐在栈上创建组件。因为要靠人工管理new和delete的出错概率要远大于在栈上的自动控制。除此之外，在堆上和在栈上创建已经没有任何区别。

如果你必须在堆上创建对象，不妨增加一句：

label->setAttribute(Qt::WA_DeleteOnClose);

这点提示足够告诉程序维护者，你已经考虑到内存问题了。

早期版本的 Qt 可能会有问题：

严重的是，label 是建立在堆上的，app 是建立在栈上的。这意味着，label 会在 app 之后析构。也就是说，label 的生命周期长于 app 的生命周期。这可是 Qt 编程的大忌。因为在 Qt 中，所有的QPaintDevice必须要在有QApplication实例的情况下创建和使用。大家好奇的话，可以提一句，QLabel继承自QWidget，QWidget则是QPaintDevice的子类。之所以上面的代码不会有问题，是因为 app 退出时，label 已经关闭，这样的话，label 的所有QPaintDevice一般都不会被访问到了。但是，如果我们的程序，在 app 退出时，组件却没有关闭，这就会造成程序崩溃。（如果你想知道，怎样做才能让 app 退出时，组件却不退出，那么豆子可以告诉你，当你的程序在打开了一个网页的下拉框时关闭窗口，你的程序就会崩溃了！）

3、Qt 学习之路 2（4）：信号槽

3.1 信号和槽概述

所谓信号槽，实际就是观察者模式。当某个事件发生之后，比如，按钮检测到自己被点击了一下，它就会发出一个信号（signal）。这种发出是没有目的的，类似广播。如果有对象对这个信号感兴趣，它就会使用连接（connect）函数，意思是，用自己的一个函数（成为槽（slot））来处理这个信号。也就是说，当信号发出时，被连接的槽函数会自动被回调。这就类似观察者模式：当发生了感兴趣的事件，某一个操作就会被自动触发。（这里提一句，Qt 的信号槽使用了额外的处理来实现，并不是 GoF 经典的观察者模式的实现方式）

3.2 connect函数

在 Qt 5 中，QObject::connect()有五个重载：

QMetaObject::Connection connect(const QObject *, const char *,
                                const QObject *, const char *,
                                Qt::ConnectionType);

QMetaObject::Connection connect(const QObject *, const QMetaMethod &,
                                const QObject *, const QMetaMethod &,
                                Qt::ConnectionType);

QMetaObject::Connection connect(const QObject *, const char *,
                                const char *,
                                Qt::ConnectionType) const;

QMetaObject::Connection connect(const QObject *, PointerToMemberFunction,
                                const QObject *, PointerToMemberFunction,
                                Qt::ConnectionType)

QMetaObject::Connection connect(const QObject *, PointerToMemberFunction,
                                Functor);

分析：

第一个，sender 类型是const QObject ，signal 的类型是const char ，receiver 类型是const QObject ，slot 类型是const char 。这个函数将 signal 和 slot 作为字符串处理。第二个，sender 和 receiver 同样是const QObject ，但是 signal 和 slot 都是const QMetaMethod &。我们可以将每个函数看做是QMetaMethod的子类。因此，这种写法可以使用QMetaMethod进行类型比对。第三个，sender 同样是const QObject ，signal 和 slot 同样是const char ，但是却缺少了 receiver。这个函数其实是将 this 指针作为 receiver。第四个，sender 和 receiver 也都存在，都是const QObject ，但是 signal 和 slot 类型则是PointerToMemberFunction。看这个名字就应该知道，这是指向成员函数的指针。第五个，前面两个参数没有什么不同，最后一个参数是Functor类型。这个类型可以接受 static 函数、全局函数以及 Lambda 表达式。

3.3 信号和槽的参数

信号槽要求信号和槽的参数一致，所谓一致，是参数类型一致。如果不一致，允许的情况是，槽函数的参数可以比信号的少，即便如此，槽函数存在的那些参数的顺序也必须和信号的前面几个一致起来。这是因为，你可以在槽函数中选择忽略信号传来的数据（也就是槽函数的参数比信号的少），但是不能说信号根本没有这个数据，你就要在槽函数中使用（就是槽函数的参数比信号的多，这是不允许的）。

Qt5 可以使用Lambda 表达式，相比起 Qt4 这是一大特色

4、Qt 学习之路 2（5）：自定义信号槽

4.1 观察者模式

信号槽不是 GUI 模块提供的，而是 Qt 核心特性之一。因此，我们可以在普通的控制台程序使用信号槽。

经典的观察者模式在讲解举例的时候通常会举报纸和订阅者的例子。有一个报纸类Newspaper，有一个订阅者类Subscriber。Subscriber可以订阅Newspaper。这样，当Newspaper有了新的内容的时候，Subscriber可以立即得到通知。在这个例子中，观察者是Subscriber，被观察者是Newspaper。在经典的实现代码中，观察者会将自身注册到被观察者的一个容器中（比如subscriber.registerTo(newspaper)）。被观察者发生了任何变化的时候，会主动遍历这个容器，依次通知各个观察者（newspaper.notifyAllSubscribers()）。

4.2 理解 Qt 中的观察者模式

只有继承了QObject类的类，才具有信号槽的能力。

只有继承了QObject类的类，才具有信号槽的能力。所以，为了使用信号槽，必须继承QObject。凡是QObject类（不管是直接子类还是间接子类），都应该在第一行代码写上Q_OBJECT。不管是不是使用信号槽，都应该添加这个宏。这个宏的展开将为我们的类提供信号槽机制、国际化机制以及 Qt 提供的不基于 C++ RTTI 的反射能力。因此，如果你觉得你的类不需要使用信号槽，就不添加这个宏，就是错误的。

4.3

其它很多操作都会依赖于这个宏。注意，这个宏将由 moc（我们会在后面章节中介绍 moc。这里你可以将其理解为一种预处理器，是比 C++ 预处理器更早执行的预处理器。） 做特殊处理，不仅仅是宏展开这么简单。moc 会读取标记了 Q_OBJECT 的头文件，生成以 moc_ 为前缀的文件，比如 newspaper.h 将生成 moc_newspaper.cpp。你可以到构建目录查看这个文件，看看到底增加了什么内容。注意，由于 moc 只处理头文件中的标记了Q_OBJECT的类声明，不会处理 cpp 文件中的类似声明。因此，如果我们的Newspaper和Reader类位于 main.cpp 中，是无法得到 moc 的处理的。解决方法是，我们手动调用 moc 工具处理 main.cpp，并且将 main.cpp 中的#include “newspaper.h”改为#include “moc_newspaper.h”就可以了。不过，这是相当繁琐的步骤，为了避免这样修改，我们还是将其放在头文件中。许多初学者会遇到莫名其妙的错误，一加上Q_OBJECT就出错，很大一部分是因为没有注意到这个宏应该放在头文件中。

4.4

信号就是一个个的函数名，返回值是 void（因为无法获得信号的返回值，所以也就无需返回任何值），参数是该类需要让外界知道的数据。信号作为函数名，不需要在 cpp 函数中添加任何实现（我们曾经说过，Qt 程序能够使用普通的 make 进行编译。没有实现的函数名怎么会通过编译？原因还是在 moc，moc 会帮我们实现信号函数所需要的函数体，所以说，moc 并不是单纯的将 Q_OBJECT 展开，而是做了很多额外的操作）。

4.5

Qt 5 中，任何成员函数、static 函数、全局函数和 Lambda 表达式都可以作为槽函数。与信号函数不同，槽函数必须自己完成实现代码。槽函数就是普通的成员函数，因此作为成员函数，也会受到 public、private 等访问控制符的影响。（我们没有说信号也会受此影响，事实上，如果信号是 private 的，这个信号就不能在类的外面连接，也就没有任何意义。）

4.6 自定义信号槽 注意事项：

（1）发送者和接收者都需要是QObject的子类（当然，槽函数是全局函数、Lambda 表达式等无需接收者的时候除外）；

（2）使用 signals 标记信号函数，信号是一个函数声明，返回 void，不需要实现函数代码；

（3）槽函数是普通的成员函数，作为成员函数，会受到 public、private、protected 的影响；

（4）使用 emit 在恰当的位置发送信号；

（5）使用QObject::connect()函数连接信号和槽。

4.7 Qt 4 与 Qt 5 的区别【重要】

（1）Reader类，receiveNewspaper()函数放在了 public slots 块中。在 Qt 4 中，槽函数必须放在由 slots 修饰的代码块中，并且要使用访问控制符进行访问控制。其原则同其它函数一样：默认是 private 的，如果要在外部访问，就应该是 public slots；如果只需要在子类访问，就应该是 protected slots。


（2）main()函数中，QObject::connect()函数，第二、第四个参数需要使用SIGNAL和SLOT这两个宏转换成字符串（具体事宜我们在上一节介绍过）。注意SIGNAL和SLOT的宏参数并不是取函数指针，而是除去返回值的函数声明，并且 const 这种参数修饰符是忽略不计的。


（3）下面说明另外一点，我们提到了“槽函数是普通的成员函数，作为成员函数，会受到 public、private、protected 的影响”，public、private 这些修饰符是供编译器在编译期检查的，因此其影响在于编译期。对于 Qt4 的信号槽连接语法，其连接是在运行时完成的，因此即便是 private 的槽函数也是可以作为槽进行连接的。但是，如果你使用了 Qt5 的新语法，新语法提供了编译期检查（取函数指针），因此取 private 函数的指针是不能通过编译的。

5、Qt 学习之路 2（6）：Qt 模块简介

注：由于原文格式很好，但是粘贴过来改格式很麻烦，而且不见得方便阅读，接下来采用粘贴原图的方法。

5.1 Qt 基础模块

5.2 Qt 扩展模块

Qt 扩展模块则有更多的选择：

5.3 Qt 4 模块

这里需要强调一点，由于 Qt 的扩展模块并不是 Qt 必须安装的部分，因此 Qt 在未来版本中可能会提供更多的扩展模块，这里给出的也仅仅是一些现在确定会包含在 Qt 5 中的一部分，另外还有一些，比如 Qt Active、Qt QA 等，则可能会在 beta 及以后版本中出现。

Qt 4 也分成若干模块，但是这些模块与 Qt 5 有些许多不同。下面是 Qt 4 的模块：

6、Qt 学习之路 2（7）：MainWindow 简介

6.1 菜单栏、任务栏、工具栏、标题栏

试着回想一下经典的主窗口，通常是由一个标题栏，一个菜单栏，若干工具栏和一个任务栏。在这些子组件之间则是我们的工作区。事实上，QMainWindow正是这样的一种布局。（这几个概念对于要做桌面程序的程序员来说十分重要，我即将做的可视化编程工具开发也是，关于这几个概念，详见：http://www.360doc.com/content/11/1215/17/8263158_172495415.shtml）

注：工具栏是可以移动的

6.2 MainWindow

如果直接运行 Qt 自建的那个工程，

7、Qt 学习之路 2（8）：添加动作

7.1 QAction 类

7.2 qrc

8、Qt 学习之路 2（9）：资源文件

8.1 资源文件编译到PE内部了

9、Qt 学习之路 2（10）：对象模型

这一章十分重要，也是对moc的讲解。经典而且不长，打算全部贴过来~~

10、Qt 学习之路 2（11）：布局管理器

我发现用图片做笔记是方便了排版，但是又带来另一个问题，那就是信息量的缺失，比如我想搜索一个词，用图片是搜索不到的，所以当时应该使用HTML编辑器，而不应该用Markdown编辑器，不过也无妨，以后重要信息自己排版，至少也要有足够的关键词索引~~~

10.1 GUI 界面与布局的引出

10.2 Qt 提供的布局管理器

（1）QHBoxLayout：按照水平方向从左到右布局；


（2）QVBoxLayout：按照竖直方向从上到下布局；


（3）QGridLayout：在一个网格中进行布局，类似于 HTML 的 table；


（4）QFormLayout：按照表格布局，每一行前面是一段文本，文本后面跟随一个组件（通常是输入框），类似 HTML 的 form；


（5）QStackedLayout：层叠的布局，允许我们将几个组件按照 Z 轴方向堆叠，可以形成向导那种一页一页的效果。

10.3 Qt 4同样的代码编译，注意connect

11、Qt 学习之路 2（13）：对话框简介

11.1 对话框

很多不能或者不适合放入主窗口的功能组件都必须放在对话框中设置。对话框通常会是一个顶层窗口，出现在程序最上层，用于实现短期任务或者简洁的用户交互。尽管 Ribbon 界面的出现在一定程度上减少了对话框的使用几率，但是，我们依然可以在最新版本的 Office 中发现不少对话框。因此，在可预见的未来，对话框会一直存在于我们的程序之中。

11.2 模态对话框和非模态对话框

对话框分为模态对话框和非模态对话框。所谓模态对话框，就是会阻塞同一应用程序中其它窗口的输入。模态对话框很常见，比如“打开文件”功能。你可以尝试一下记事本的打开文件，当打开文件对话框出现时，我们是不能对除此对话框之外的窗口部分进行操作的。与此相反的是非模态对话框，例如查找对话框，我们可以在显示着查找对话框的同时，继续对记事本的内容进行编辑。

Qt 支持模态对话框和非模态对话框。其中，Qt 有两种级别的模态对话框：应用程序级别的模态和窗口级别的模态，默认是应用程序级别的模态。应用程序级别的模态是指，当该种模态的对话框出现时，用户必须首先对对话框进行交互，直到关闭对话框，然后才能访问程序中其他的窗口。窗口级别的模态是指，该模态仅仅阻塞与对话框关联的窗口，但是依然允许用户与程序中其它窗口交互。窗口级别的模态尤其适用于多窗口模式，更详细的讨论可以看以前发表过的文章。

可见 Qt 的强大之处



在这里，我插播一点自己的东西~~

我这样实现了：

void MainWindow::open()
{
    //模态
    //QDialog dialog(this); //指定parent指针
    //dialog.setWindowTitle(tr("Hello, dialog!"));
    //dialog.exec();

    //非模态，因为不能在栈上建立，否则一闪而过
    QDialog *dialog = new QDialog(this);
    dialog->setWindowTitle(tr("Hello, dialog!"));
    dialog->show();
}

这样的确就解决问题了~~

之前那段话是出自Qt 学习之路 2（10）：对象模型



这是 Qt 一个非常重要的机制，一定要记牢~~



大胆在堆上创建~~

12、Qt 学习之路 2（14）：对话框数据传递

12.1 原因

模态对话框使用了exec()函数将其显示出来。exec()函数的真正含义是开启一个新的事件循环（我们会在后面的章节中详细介绍有关事件的概念）。所谓事件循环，可以理解成一个无限循环。Qt 在开启了事件循环之后，系统发出的各种事件才能够被程序监听到。这个事件循环相当于一种轮询的作用。既然是无限循环，当然在开启了事件循环的地方，代码就会被阻塞，后面的语句也就不会被执行到。因此，对于使用了exec()显示的模态对话框，我们可以在exec()函数之后直接从对话框的对象获取到数据值。

13、Qt 学习之路 2（18）：事件

为了保证快速上手，中间跳过较为独立的介绍模块的几章，以后再仔细看，先跳到事件这一章。不过文章确实字字珠玑，值得仔细阅读品味。

13.1 事件驱动

事件也就是我们通常说的“事件驱动（event drive）”程序设计的基础概念。事件的出现，使得程序代码不会按照原始的线性顺序执行。想想看，从最初的 C 语言开始，我们的程序就是以一种线性的顺序执行代码：这一条语句执行之后，开始执行下一条语句；这一个函数执行过后，开始执行下一个函数。这种类似“批处理”的程序设计风格显然不适合于处理复杂的用户交互。我们来想象一下用户交互的情景：我们设计了一堆功能放在界面上，用户点击了“打开文件”，于是开始执行打开文件的操作；用户点击了“保存文件”，于是开始执行保存文件的操作。我们不知道用户究竟想进行什么操作，因此也就不能预测接下来将会调用哪一个函数。如果我们设计了一个“文件另存为”的操作，如果用户不点击，这个操作将永远不会被调用。这就是所谓的“事件驱动”，我们的程序的执行顺序不再是线性的，而是由一个个事件驱动着程序继续执行。没有事件，程序将阻塞在那里，不执行任何代码。

相比于其他 GUI 框架，Qt 给了我们额外的选择：信号槽。

13.2 事件和信号槽

但是这并不是一个东西。

13.3 事件处理的过程