1. Explicitly calling a Python slot from QML. If the Python object is exposed to QML using setContextProperty, you can call any slot of the object explicitly from QML, as shown in qmltopy1. First, you define a class in Python, inheriting from QObject: class Console(QtCore.QObject): @QtCore.Slot(str) def outputStr(self, s): print s.
2. Traditional syntax: SIGNAL and SLOT QtCore.SIGNAL and QtCore.SLOT macros allow Python to interface with Qt signal and slot delivery mechanisms. This is the old way of using signals and slots. The example below uses the well known clicked signal from a QPushButton.The connect method has a non python-friendly syntax.

1. Qt Connect Parent Slot Machine
2. Qt Connect Signal Parent Slot

Build complex application behaviours using signals and slots, and override widget event handling with custom events.

Qt connects widgets by means of a nice designed scheme based on the idea that objectS may send signalS of different typeS to a single object instance: This is a screenshot of the example code running. Qt/C - Tutorial 073. Signals and slots. Connecting Slots to Overloaded Signals in the Qt5 Syntax. Quite a frequent problem when working with signals with slots in Qt5, according to my observations on the forum, is the connection of slots in the syntax on the pointers to signals having an over.

As already described, every interaction the user has with a Qt application causes an Event. There are multiple types of event, each representing a difference type of interaction — e.g. mouse or keyboard events.

Events that occur are passed to the event-specific handler on the widget where the interaction occurred. For example, clicking on a widget will cause a QMouseEvent to be sent to the .mousePressEvent event handler on the widget. This handler can interrogate the event to find out information, such as what triggered the event and where specifically it occurred.

You can intercept events by subclassing and overriding the handler function on the class, as you would for any other function. You can choose to filter, modify, or ignore events, passing them through to the normal handler for the event by calling the parent class function with super().

However, imagine you want to catch an event on 20 different buttons. Subclassing like this now becomes an incredibly tedious way of catching, interpreting and handling these events.

Qt Connect Parent Slot Machine

Thankfully Qt offers a neater approach to receiving notification of things happening in your application: Signals.

Signals

Instead of intercepting raw events, signals allow you to 'listen' for notifications of specific occurrences within your application. While these can be similar to events — a click on a button — they can also be more nuanced — updated text in a box. Data can also be sent alongside a signal - so as well as being notified of the updated text you can also receive it.

The receivers of signals are called Slots in Qt terminology. A number of standard slots are provided on Qt classes to allow you to wire together different parts of your application. However, you can also use any Python function as a slot, and therefore receive the message yourself.

Load up a fresh copy of `MyApp_window.py` and save it under a new name for this section. The code is copied below if you don't have it yet.

Basic signals

First, let's look at the signals available for our QMainWindow. You can find this information in the Qt documentation. Scroll down to the Signals section to see the signals implemented for this class.

Qt 5 Documentation — QMainWindow Signals

As you can see, alongside the two QMainWindow signals, there are 4 signals inherited from QWidget and 2 signals inherited from Object. If you click through to the QWidget signal documentation you can see a .windowTitleChanged signal implemented here. Next we'll demonstrate that signal within our application.

Qt 5 Documentation — Widget Signals

The code below gives a few examples of using the windowTitleChanged signal.

Try commenting out the different signals and seeing the effect on what the slot prints.

We start by creating a function that will behave as a ‘slot’ for our signals.

Then we use .connect on the .windowTitleChanged signal. We pass the function that we want to be called with the signal data. In this case the signal sends a string, containing the new window title.

If we run that, we see that we receive the notification that the window title has changed.

Events

Next, let’s take a quick look at events. Thanks to signals, for most purposes you can happily avoid using events in Qt, but it’s important to understand how they work for when they are necessary.

As an example, we're going to intercept the .contextMenuEvent on QMainWindow. This event is fired whenever a context menu is about to be shown, and is passed a single value event of type QContextMenuEvent.

To intercept the event, we simply override the object method with our new method of the same name. So in this case we can create a method on our MainWindow subclass with the name contextMenuEvent and it will receive all events of this type.

If you add the above method to your MainWindow class and run your program you will discover that right-clicking in your window now displays the message in the print statement.

Sometimes you may wish to intercept an event, yet still trigger the default (parent) event handler. You can do this by calling the event handler on the parent class using super as normal for Python class methods.

This allows you to propagate events up the object hierarchy, handling only those parts of an event handler that you wish.

However, in Qt there is another type of event hierarchy, constructed around the UI relationships. Widgets that are added to a layout, within another widget, may opt to pass their events to their UI parent. In complex widgets with multiple sub-elements this can allow for delegation of event handling to the containing widget for certain events.

However, if you have dealt with an event and do not want it to propagate in this way you can flag this by calling .accept() on the event.

Alternatively, if you do want it to propagate calling .ignore() will achieve this.

In this section we've covered signals, slots and events. We've demonstratedsome simple signals, including how to pass less and more data using lambdas.We've created custom signals, and shown how to intercept events, pass onevent handling and use .accept() and .ignore() to hide/show eventsto the UI-parent widget. In the next section we will go on to takea look at two common features of the GUI — toolbars and menus.

EnArBgDeElEsFaFiFrHiHuItJaKnKoMsNlPlPtRuSqThTrUkZh

This page was used to describe the new signal and slot syntax during its development. The feature is now released with Qt 5.

• Differences between String-Based and Functor-Based Connections (Official documentation)
• Introduction (Woboq blog)
• Implementation Details (Woboq blog)

Note: This is in addition to the old string-based syntax which remains valid.

• 1Connecting in Qt 5
• 2Disconnecting in Qt 5
• 4Error reporting
• 5Open questions

Connecting in Qt 5

There are several ways to connect a signal in Qt 5.

Old syntax

Qt 5 continues to support the old string-based syntax for connecting signals and slots defined in a QObject or any class that inherits from QObject (including QWidget)

New: connecting to QObject member

Here's Qt 5's new way to connect two QObjects and pass non-string objects:

Pros

• Compile time check of the existence of the signals and slot, of the types, or if the Q_OBJECT is missing.
• Argument can be by typedefs or with different namespace specifier, and it works.
• Possibility to automatically cast the types if there is implicit conversion (e.g. from QString to QVariant)
• It is possible to connect to any member function of QObject, not only slots.

Cons

• More complicated syntax? (you need to specify the type of your object)
• Very complicated syntax in cases of overloads? (see below)
• Default arguments in slot is not supported anymore.

New: connecting to simple function

The new syntax can even connect to functions, not just QObjects:

Pros

• Can be used with std::bind:

• Can be used with C++11 lambda expressions:

Cons

• There is no automatic disconnection when the 'receiver' is destroyed because it's a functor with no QObject. However, since 5.2 there is an overload which adds a 'context object'. When that object is destroyed, the connection is broken (the context is also used for the thread affinity: the lambda will be called in the thread of the event loop of the object used as context).

Disconnecting in Qt 5

As you might expect, there are some changes in how connections can be terminated in Qt 5, too.

Old way

You can disconnect in the old way (using SIGNAL, SLOT) but only if

• You connected using the old way, or
• If you want to disconnect all the slots from a given signal using wild card character

Symetric to the function pointer one

Only works if you connected with the symmetric call, with function pointers (Or you can also use 0 for wild card)In particular, does not work with static function, functors or lambda functions.

New way using QMetaObject::Connection

Works in all cases, including lambda functions or functors.

Asynchronous made easier

With C++11 it is possible to keep the code inline

Here's a QDialog without re-entering the eventloop, and keeping the code where it belongs:

Another example using QHttpServer : http://pastebin.com/pfbTMqUm

Error reporting

Tested with GCC.

Fortunately, IDEs like Qt Creator simplifies the function naming

Missing Q_OBJECT in class definition

Type mismatch

Open questions

Default arguments in slot

If you have code like this:

The old method allows you to connect that slot to a signal that does not have arguments.But I cannot know with template code if a function has default arguments or not.So this feature is disabled.

There was an implementation that falls back to the old method if there are more arguments in the slot than in the signal.This however is quite inconsistent, since the old method does not perform type-checking or type conversion. It was removed from the patch that has been merged.

Qt Connect Signal Parent Slot

Overload

As you might see in the example above, connecting to QAbstractSocket::error is not really beautiful since error has an overload, and taking the address of an overloaded function requires explicit casting, e.g. a connection that previously was made as follows:

connect(mySpinBox, SIGNAL(valueChanged(int)), mySlider, SLOT(setValue(int));

cannot be simply converted to:

...because QSpinBox has two signals named valueChanged() with different arguments. Instead, the new code needs to be:

Unfortunately, using an explicit cast here allows several types of errors to slip past the compiler. Adding a temporary variable assignment preserves these compile-time checks:

Some macro could help (with C++11 or typeof extensions). A template based solution was introduced in Qt 5.7: qOverload

The best thing is probably to recommend not to overload signals or slots …

… but we have been adding overloads in past minor releases of Qt because taking the address of a function was not a use case we support. But now this would be impossible without breaking the source compatibility.

Disconnect

Should QMetaObject::Connection have a disconnect() function?

The other problem is that there is no automatic disconnection for some object in the closure if we use the syntax that takes a closure.One could add a list of objects in the disconnection, or a new function like QMetaObject::Connection::require

Callbacks

Function such as QHostInfo::lookupHost or QTimer::singleShot or QFileDialog::open take a QObject receiver and char* slot.This does not work for the new method.If one wants to do callback C++ way, one should use std::functionBut we cannot use STL types in our ABI, so a QFunction should be done to copy std::function.In any case, this is irrelevant for QObject connections.