To capture events generated by GUI-elements in PyQt the signal and slots mechanism from Qt is used. Signals: signals are emitted when a user interacts with a Qt widget (e.g. The user clicks a button). Slots: slots can be connected to signals and act upon receiving the signal. It is possible to connect multiple slots to one signal. With PyQt there are three different ways one can connect a. Signals and Slots. Signals and slots are used for communication between objects. The signal/slot mechanism is a central feature of Qt and probably the part that differs most from other toolkits. In GUI programming we often want a change in one widget to be notified to another widget. Aha1980 Qt Champions 2018 last edited by @Babs @Babs It is of course possible to connect multiple slots to one signal - that's one of the essences of Signals&Slots. If you, however, react to this signal with a method like readFrames, then the second slot will have nothing to read, as the buffer is already empty.

1. Qt Signal Slot Connect
2. Qt Signals And Slots Example
3. Qt Signals And Slots Tutorial
4. Qt Connect Class Slots To Designer Signals

QThread inherits QObject. It emits signals to indicate that the thread started or finished executing, and provides a few slots as well.

More interesting is that QObjects can be used in multiple threads, emit signals that invoke slots in other threads, and post events to objects that 'live' in other threads. This is possible because each thread is allowed to have its own event loop.

QObject Reentrancy

QObject is reentrant. Most of its non-GUI subclasses, such as QTimer, QTcpSocket, QUdpSocket, QFtp, and QProcess, are also reentrant, making it possible to use these classes from multiple threads simultaneously. Note that these classes are designed to be created and used from within a single thread; creating an object in one thread and calling its functions from another thread is not guaranteed to work. There are three constraints to be aware of:

• The child of a QObject must always be created in the thread where the parent was created. This implies, among other things, that you should never pass the QThread object (this) as the parent of an object created in the thread (since the QThread object itself was created in another thread).
• Event driven objects may only be used in a single thread. Specifically, this applies to the timer mechanism and the network module. For example, you cannot start a timer or connect a socket in a thread that is not the object's thread.
• You must ensure that all objects created in a thread are deleted before you delete the QThread. This can be done easily by creating the objects on the stack in your run() implementation.

Although QObject is reentrant, the GUI classes, notably QWidget and all its subclasses, are not reentrant. They can only be used from the main thread. As noted earlier, QCoreApplication::exec() must also be called from that thread.

In practice, the impossibility of using GUI classes in other threads than the main thread can easily be worked around by putting time-consuming operations in a separate worker thread and displaying the results on screen in the main thread when the worker thread is finished. This is the approach used for implementing the Mandelbrot and the Blocking Fortune Client example.

Per-Thread Event Loop

Each thread can have its own event loop. The initial thread starts its event loops using QCoreApplication::exec(); other threads can start an event loop using QThread::exec(). Like QCoreApplication, QThread provides an exit(int) function and a quit() slot.

Qt Signal Slot Connect

An event loop in a thread makes it possible for the thread to use certain non-GUI Qt classes that require the presence of an event loop (such as QTimer, QTcpSocket, and QProcess). It also makes it possible to connect signals from any threads to slots of a specific thread. This is explained in more detail in the Signals and Slots Across Threads section below.

A QObject instance is said to live in the thread in which it is created. Events to that object are dispatched by that thread's event loop. The thread in which a QObject lives is available using QObject::thread().

Note that for QObjects that are created before QApplication, QObject::thread() returns zero. This means that the main thread will only handle posted events for these objects; other event processing is not done at all for objects with no thread. Use the QObject::moveToThread() function to change the thread affinity for an object and its children (the object cannot be moved if it has a parent).

Calling delete on a QObject from a thread other than the one that owns the object (or accessing the object in other ways) is unsafe, unless you guarantee that the object isn't processing events at that moment. Use QObject::deleteLater() instead, and a DeferredDelete event will be posted, which the event loop of the object's thread will eventually pick up. By default, the thread that owns a QObject is the thread that creates the QObject, but not after QObject::moveToThread() has been called.

If no event loop is running, events won't be delivered to the object. For example, if you create a QTimer object in a thread but never call exec(), the QTimer will never emit its timeout() signal. Calling deleteLater() won't work either. (These restrictions apply to the main thread as well.)

Qt Signals And Slots Example

You can manually post events to any object in any thread at any time using the thread-safe function QCoreApplication::postEvent(). The events will automatically be dispatched by the event loop of the thread where the object was created.

Event filters are supported in all threads, with the restriction that the monitoring object must live in the same thread as the monitored object. Similarly, QCoreApplication::sendEvent() (unlike postEvent()) can only be used to dispatch events to objects living in the thread from which the function is called.

Accessing QObject Subclasses from Other Threads

QObject and all of its subclasses are not thread-safe. This includes the entire event delivery system. It is important to keep in mind that the event loop may be delivering events to your QObject subclass while you are accessing the object from another thread.

If you are calling a function on an QObject subclass that doesn't live in the current thread and the object might receive events, you must protect all access to your QObject subclass's internal data with a mutex; otherwise, you may experience crashes or other undesired behavior.

Like other objects, QThread objects live in the thread where the object was created -- not in the thread that is created when QThread::run() is called. It is generally unsafe to provide slots in your QThread subclass, unless you protect the member variables with a mutex.

On the other hand, you can safely emit signals from your QThread::run() implementation, because signal emission is thread-safe.

Signals and Slots Across Threads

Qt supports these signal-slot connection types:

• Auto Connection (default) If the signal is emitted in the thread which the receiving object has affinity then the behavior is the same as the Direct Connection. Otherwise, the behavior is the same as the Queued Connection.'
• Direct Connection The slot is invoked immediately, when the signal is emitted. The slot is executed in the emitter's thread, which is not necessarily the receiver's thread.
• Queued Connection The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread.
• Blocking Queued Connection The slot is invoked as for the Queued Connection, except the current thread blocks until the slot returns.

  Note: Using this type to connect objects in the same thread will cause deadlock.

• Unique Connection The behavior is the same as the Auto Connection, but the connection is made only if it does not duplicate an existing connection. i.e., if the same signal is already connected to the same slot for the same pair of objects, then the connection is not made and connect() returns false.

The connection type can be specified by passing an additional argument to connect(). Be aware that using direct connections when the sender and receiver live in different threads is unsafe if an event loop is running in the receiver's thread, for the same reason that calling any function on an object living in another thread is unsafe.

QObject::connect() itself is thread-safe.

The Mandelbrot example uses a queued connection to communicate between a worker thread and the main thread. To avoid freezing the main thread's event loop (and, as a consequence, the application's user interface), all the Mandelbrot fractal computation is done in a separate worker thread. The thread emits a signal when it is done rendering the fractal.

Similarly, the Blocking Fortune Client example uses a separate thread for communicating with a TCP server asynchronously.

© 2016 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.

Signals and slots are used for communication between objects. Thesignal/slot mechanism is a central feature of Qt and probably thepart that differs most from other toolkits.

In GUI programming we often want a change in one widget to be notifiedto another widget. More generally, we want objects of any kind to beable to communicate with one another. For example if we were parsingan XML file we might want to notify a list view that we're using torepresent the XML file's structure whenever we encounter a new tag.

Older toolkits achieve this kind of communication using callbacks. Acallback is a pointer to a function, so if you want a processingfunction to notify you about some event you pass a pointer to anotherfunction (the callback) to the processing function. The processingfunction then calls the callback when appropriate. Callbacks have twofundamental flaws. Firstly they are not type safe. We can never becertain that the processing function will call the callback with thecorrect arguments. Secondly the callback is strongly coupled to theprocessing function since the processing function must know whichcallback to call.

An abstract view of some signals and slots connections

In Qt we have an alternative to the callback technique. We use signalsand slots. A signal is emitted when a particular event occurs. Qt'swidgets have many pre-defined signals, but we can always subclass toadd our own. A slot is a function that is called in reponse to aparticular signal. Qt's widgets have many pre-defined slots, but it iscommon practice to add your own slots so that you can handle thesignals that you are interested in.

The signals and slots mechanism is type safe: the signature of asignal must match the signature of the receiving slot. (In fact a slotmay have a shorter signature than the signal it receives because itcan ignore extra arguments.) Since the signatures are compatible, thecompiler can help us detect type mismatches. Signals and slots areloosely coupled: a class which emits a signal neither knows nor careswhich slots receive the signal. Qt's signals and slots mechanismensures that if you connect a signal to a slot, the slot will becalled with the signal's parameters at the right time. Signals andslots can take any number of arguments of any type. They arecompletely typesafe: no more callback core dumps!

All classes that inherit from QObject or one of its subclasses(e.g. QWidget) can contain signals and slots. Signals are emitted byobjects when they change their state in a way that may be interestingto the outside world. This is all the object does to communicate. Itdoes not know or care whether anything is receiving the signals itemits. This is true information encapsulation, and ensures that theobject can be used as a software component.

An example of signals and slots connections

Slots can be used for receiving signals, but they are also normalmember functions. Just as an object does not know if anything receivesits signals, a slot does not know if it has any signals connected toit. This ensures that truly independent components can be created withQt.

You can connect as many signals as you want to a single slot, and asignal can be connected to as many slots as you desire. It is evenpossible to connect a signal directly to another signal. (This willemit the second signal immediately whenever the first is emitted.)

Together, signals and slots make up a powerful component programmingmechanism.

A Small Example

A minimal C++ class declaration might read:

A small Qt class might read:

This class has the same internal state, and public methods to access thestate, but in addition it has support for component programming usingsignals and slots: this class can tell the outside world that its statehas changed by emitting a signal, valueChanged(), and it hasa slot which other objects can send signals to.

All classes that contain signals or slots must mention Q_OBJECT intheir declaration.

Slots are implemented by the application programmer.Here is a possible implementation of Foo::setValue():

The line emit valueChanged(v) emits the signalvalueChanged from the object. As you can see, you emit asignal by using emit signal(arguments).

Here is one way to connect two of these objects together:

Calling a.setValue(79) will make a emit a valueChanged()signal, which b will receive in its setValue() slot,i.e. b.setValue(79) is called. b will then, in turn,emit the same valueChanged() signal, but since no slot has beenconnected to b's valueChanged() signal, nothing happens (thesignal is ignored).

Note that the setValue() function sets the value and emitsthe signal only if v != val. This prevents infinite loopingin the case of cyclic connections (e.g. if b.valueChanged()were connected to a.setValue()).

A signal is emitted for every connection you make, so if youduplicate a connection, two signals will be emitted. You can alwaysbreak a connection using QObject::disconnect().

This example illustrates that objects can work together without knowingabout each other, as long as there is someone around to set up aconnection between them initially.

The preprocessor changes or removes the signals, slots andemit keywords so that the compiler is presented with standard C++.

Run the moc on class definitions that containsignals or slots. This produces a C++ source file which should be compiledand linked with the other object files for the application. If you useqmake, the makefile rules toautomatically invoke the moc will be added toyour makefile for you.

Signals

Signals are emitted by an object when its internal state has changedin some way that might be interesting to the object's client or owner.Only the class that defines a signal and its subclasses can emit thesignal.

A list box, for example, emits both clicked() andcurrentChanged() signals. Most objects will probably only beinterested in currentChanged() which gives the current list itemwhether the user clicked it or used the arrow keys to move to it. Butsome objects may only want to know which item was clicked. If thesignal is interesting to two different objects you just connect thesignal to slots in both objects.

When a signal is emitted, the slots connected to it are executedimmediately, just like a normal function call. The signal/slotmechanism is totally independent of any GUI event loop. Theemit will return when all slots have returned.

If several slots are connected to one signal, the slots will beexecuted one after the other, in an arbitrary order, when the signalis emitted.

Signals are automatically generated by the mocand must not be implemented in the .cpp file. They can never havereturn types (i.e. use void).

A note about arguments. Our experience shows that signals and slotsare more reusable if they do not use special types. If QScrollBar::valueChanged() were to use a special type such as thehypothetical QRangeControl::Range, it could only be connected toslots designed specifically for QRangeControl. Something as simple asthe program in Tutorial #1 part 5would be impossible.

Slots

A slot is called when a signal connected to it is emitted. Slots arenormal C++ functions and can be called normally; their only specialfeature is that signals can be connected to them. A slot's argumentscannot have default values, and, like signals, it is rarely wise touse your own custom types for slot arguments.

Qt Signals And Slots Tutorial

Since slots are normal member functions with just a little extraspice, they have access rights like ordinary member functions. Aslot's access right determines who can connect to it:

A public slots section contains slots that anyone can connectsignals to. This is very useful for component programming: you createobjects that know nothing about each other, connect their signals andslots so that information is passed correctly, and, like a modelrailway, turn it on and leave it running.

A protected slots section contains slots that this class and itssubclasses may connect signals to. This is intended for slots that arepart of the class's implementation rather than its interface to therest of the world.

A private slots section contains slots that only the class itselfmay connect signals to. This is intended for very tightly connectedclasses, where even subclasses aren't trusted to get the connectionsright.

You can also define slots to be virtual, which we have found quiteuseful in practice.

The signals and slots mechanism is efficient, but not quite as fast as'real' callbacks. Signals and slots are slightly slower because of theincreased flexibility they provide, although the difference for realapplications is insignificant. In general, emitting a signal that isconnected to some slots, is approximately ten times slower thancalling the receivers directly, with non-virtual function calls. Thisis the overhead required to locate the connection object, to safelyiterate over all connections (i.e. checking that subsequent receivershave not been destroyed during the emission) and to marshall anyparameters in a generic fashion. While ten non-virtual function callsmay sound like a lot, it's much less overhead than any 'new' or'delete' operation, for example. As soon as you perform a string,vector or list operation that behind the scene requires 'new' or'delete', the signals and slots overhead is only responsible for avery small proportion of the complete function call costs. The same istrue whenever you do a system call in a slot; or indirectly call morethan ten functions. On an i586-500, you can emit around 2,000,000signals per second connected to one receiver, or around 1,200,000 persecond connected to two receivers. The simplicity and flexibility ofthe signals and slots mechanism is well worth the overhead, which yourusers won't even notice.

Meta Object Information

The meta object compiler (moc) parses the classdeclaration in a C++ file and generates C++ code that initializes themeta object. The meta object contains the names of all the signal andslot members, as well as pointers to these functions. (For moreinformation on Qt's Meta Object System, see Whydoesn't Qt use templates for signals and slots?.)

The meta object contains additional information such as the object's class name. You can also check if an objectinherits a specific class, for example:

A Real Example

Here is a simple commented example (code fragments from qlcdnumber.h ).

QLCDNumber inherits QObject, which has most of the signal/slotknowledge, via QFrame and QWidget, and #include's the relevantdeclarations.

Q_OBJECT is expanded by the preprocessor to declare several memberfunctions that are implemented by the moc; if you get compiler errorsalong the lines of 'virtual function QButton::className not defined'you have probably forgotten to run the moc or toinclude the moc output in the link command.

It's not obviously relevant to the moc, but if you inherit QWidget youalmost certainly want to have the parent and namearguments in your constructors, and pass them to the parentconstructor.

Some destructors and member functions are omitted here; the mocignores member functions.

QLCDNumber emits a signal when it is asked to show an impossiblevalue.

If you don't care about overflow, or you know that overflow cannotoccur, you can ignore the overflow() signal, i.e. don't connect it toany slot.

Qt Connect Class Slots To Designer Signals

If, on the other hand, you want to call two different error functionswhen the number overflows, simply connect the signal to two differentslots. Qt will call both (in arbitrary order).

A slot is a receiving function, used to get information about statechanges in other widgets. QLCDNumber uses it, as the code aboveindicates, to set the displayed number. Since display() is partof the class's interface with the rest of the program, the slot ispublic.

Several of the example programs connect the newValue() signal of aQScrollBar to the display() slot, so the LCD number continuously showsthe value of the scroll bar.

Note that display() is overloaded; Qt will select the appropriate versionwhen you connect a signal to the slot. With callbacks, you'd have to findfive different names and keep track of the types yourself.

Some irrelevant member functions have been omitted from thisexample.