Qt 事件和信号的关系
Qt的事件是windows的底层消息封装而成的。这个消息和MFC里的消息是同一概念，都是指键盘、鼠标等的按压、松开等消息。例如按下键盘后，windows系统会发出一个 WM_KEYDOWN的消息，Qt捕获这个消息后，将其转换成 Qt::Key_Down 事件。
Qt的事件是较为底层的概念。先有事件，然后才有信号。即：消息 -> 事件 -> 信号
总结：windows发出消息，Qt捕获消息后转换成事件，再由事件处理后发出信号。
一般来说，如果仅仅是使用Qt的控件，那么只需关心这个控件能发出什么信号，但如果需要深一层的定制控件，则需要关心事件，并重写事件处理函数。
线程与事件循环
QThread中run()的默认实现调用了exec()，从而创建一个QEventLoop对象，由QEventLoop对象处理线程中事件队列（每一个线程都有一个属于自己的事件队列）中的事件。exec()在其内部不断做着循环遍历事件队列的工作，调用QThread的quit()或exit()方法使退出线程，尽量不要使用terminate()退出线程，terminate()退出线程过于粗暴，造成资源不能释放，甚至互斥锁还处于加锁状态。
线程中的事件循环，使得线程可以使用那些需要事件循环的非GUI 类(如，QTimer,QTcpSocket,QProcess)。
在QApplication前创建的对象，QObject::thread()返回NULL,意味着主线程仅为这些对象处理投递事件，不会为没有所属线程的对象处理另外的事件。可以用QObject::moveToThread()来改变对象及其子对象的线程亲缘关系，假如对象有父亲，不能移动这种关系。在另一个线程(而不是创建它的线程)中delete QObject对象是不安全的。除非可以保证在同一时刻对象不在处理事件。可以用QObject::deleteLater(),它会投递一个DeferredDelete事件，这会被对象线程的事件循环最终选取到。假如没有事件循环运行，事件不会分发给对象。假如在一个线程中创建了一个QTimer对象，但从没有调用过exec(),那么QTimer就不会发射它的timeout()信号，deleteLater()也不会工作。可以手工使用线程安全的函数QCoreApplication::postEvent()，在任何时候，给任何线程中的任何对象投递一个事件，事件会在那个创建了对象的线程中通过事件循环派发。事件过滤器在所有线程中也被支持，不过它限定被监视对象与监视对象生存在同一线程中。QCoreApplication::sendEvent(不是postEvent()),仅用于在调用此函数的线程中向目标对象投递事件。
GUI系统的设计原则：
所有界面组件的创建只能在GUI线程（主线程）中完成。子线程与界面组件的通信有两种方式：
A、信号槽方式
B、发送自定事件方式
QT多线程
https://blog.51cto.com/9291927/1879757
QT事件循环源码分析
https://blog.51cto.com/9291927/1868744
QT为什么只能在主线程里进行UI操作
直观的看，因为在主线程里面运行的app->exec()，所以这样次线程里面的ui无法接受到系统事件。
对Qt而言，一个进程里和窗口系统(譬如Win32的GDI, linux下的X11)UI事件关联的只有主UI线程，而并没有设计成多线程和系统窗口系统同时交互（复杂性，安全性，性能等原因），这应该是根源。
