Recently i've run into a problem in my signals and slots. I'm trying to transfer information from mainWindow into another class called InteriorPaint, but I don't know where I can initialize the connection because if I do it in the constructor of either class, it misses the object that it needs to connect to.
When we change a widget in GUI programming, we often want another widget to be notified. More generally, we want objects of any kind to be able to communicate with one another. For instance, if a user clicks a Close button, we probably want the window's close() function to be called. Signals and slots are Qt Jambi's mechanism for such communication between objects.
- 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.
- 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.
In this overview, we will examine how to implement and use signals and slots in Qt Jambi. We look at how the mechanism works, its intended usage, and give an example.
Signal and Slots
A signal is emitted when a particular event occurs. Qt Jambi's widgets have many predefined signals, but we can always subclass widgets to add our own signals to them. A slot is a method that is called in response to a particular signal. Qt's widgets have many pre-defined slots, but it is common practice to subclass widgets and add your own slots so that you can handle the signals that you are interested in.The signals and slots mechanism is type safe: The signature of a signal must match the signature of the receiving slot. Signals and slots are loosely coupled: A class which emits a signal neither knows nor cares which slots receive the signal. Qt Jambis's signals and slots mechanism ensures that if you connect a signal to a slot, the slot will be called with the signal's parameters at the right time.
All classes that inherit from QSignalEmitter - which is an ancestor of all Qt Jambi classes - or one of its subclasses (e.g., QWidget) can contain signals and slots. Signals are emitted by objects when they change their state in a way that may be interesting to other objects. This is all the object does to communicate. It does not know or care whether anything is receiving the signals it emits. This is true information encapsulation, and ensures that the object can be used as a software component.
All normal member methods can be used as slots, so there are no specific requirements for a method to function as a slot. Just as an object does not know if anything receives its signals, a slot does not know if it has any signals connected to it. This ensures that truly independent components can be created with Qt Jambi.
You can connect as many signals as you want to a single slot, and a signal can be connected to as many slots as you need. It is even possible to connect a signal directly to another signal. (This will emit the second signal immediately whenever the first is emitted.)
Together, signals and slots make up a powerful component programming mechanism.
An Example
A minimal Java class using signals and slots may read: The class manages a counter, which is stored in the private member value. The signal valueChanged is emitted whenever value changes. We will now go through the class step-by-step to describe how signals are created and emitted. Signals in Qt Jambi are implemented in classes named Signal1, Signal2 to Signal9. The number of the class indicates the number of parameters the signal has. The type of each parameter is specified as a generic. It is customary to declare signals as public rather than to provide access methods for them. The getter for value is annotated with @QtBlockedSlot. This prevents the method from being used as a slot. The annotation is mostly provided for consitency with Qt, in which functions must explicitly be declared as slots. To emit a signal, you simply invoke its emit method with the necessary parameters (all signal classes implements an emit method). The signal will then invoke the slots and other signals it is connected to.
Note that the signal is only emitted if val != value. This prevents infinite looping in the case of cyclic connections (e.g., if b.valueChanged() were connected to a.setValue()). We move on the see how signals are connected to slots. When you connect a signal to a slot, you specify the object that will receive the signal and the method signature of the slot. It is only the type of the method parameters that should be specified and not the parameter names.
Calling a.setValue(12) makes a emit a valueChanged(12) signal, which b will receive in its setValue() slot, i.e. b.setValue(12) is called. Then b emits the same valueChanged() signal, but since no slot has been connected to b's valueChanged() signal, the signal is ignored.
A signal is emitted for every connection you make; if you duplicate a connection, two signals will be emitted. You can always break a connection using the signal classes disconnect() method.
Signals
Signals are emitted by an object when its internal state has changed in some way that might be interesting to the object's client or owner. Only the class that defines a signal and its subclasses should emit the signal.When a signal is emitted, the slots connected to it are executed immediately, just like a normal method call. When this happens, the signals and slots mechanism is totally independent of any GUI event loop. Execution of the code following call to emit will occur once all slots have returned. The situation is slightly different when using queued connections; in such a case, the code following the call to the signals emit method will continue immediately, and the slots will be executed later.
If several slots are connected to one signal, the slots will be executed one after the other when the signal is emitted.
Slots
A slot is called when a signal connected to it is emitted. Slots are normal Java methods and can be invoked normally; when we talk about a slot, we simply mean a method that happens to be used as a slot.Since slots are normal member methods, they follow the normal Java rules when called directly. However, as slots, they can be invoked by any component, regardless of its access level, via a signal-slot connection. This means that a signal emitted from an instance of an arbitrary class can cause a private slot to be invoked in an instance of an unrelated class.
| Copyright © 2009 Nokia Corporation and/or its subsidiary(-ies) | Trademarks |
Qt5 alpha has been released. One of the features which I have been working on is a new syntax for signals and slot.This blog entry will present it.
Here is how you would connect a signal to a slot:
What really happens behind the scenes is that the SIGNAL and SLOT macros will convert their argument to a string. Then QObject::connect() will compare those strings with the introspection data collected by the moc tool.
What's the problem with this syntax?
While working fine in general, we can identify some issues:
- No compile time check: All the checks are done at run-time by parsing the strings. That means if you do a typo in the name of the signal or the slot, it will compile but the connection will not be made, and you will only notice a warning in the standard output.
- Since it operates on the strings, the type names of the slot must match exactly the ones of the signal. And they also need to be the same in the header and in the connect statement. This means it won't work nicely if you want to use
typedefor namespaces
In the upcoming Qt5, an alternative syntax exist. The former syntax will still work. But you can now also use this new way of connecting your signals to your slots:
Which one is the more beautiful is a matter of taste. One can quickly get used to the new syntax.
So apart from the aesthetic point of view, let us go over some of the things that it brings us:
Compile-time checking
You will get a compiler error if you misspelled the signal or slot name, or if the arguments of your slot do not match those from the signal.
This might save you some time while you are doing some re-factoring and change the name or arguments of signals or slots.
An effort has been made, using static_assert to get nice compile errors if the arguments do not match or of you miss a Q_OBJECT
Arguments automatic type conversion
Not only you can now use typedef or namespaces properly, but you can also connect signalsto slots that take arguments of different types if an implicit conversion is possible
In the following example, we connect a signal that has a QString as a parameter to a slot that takes a QVariant. It works because QVariant has an implicit constructor that takes a QString
Connecting to any function
As you might have seen in the previous example, the slot was just declared as publicand not as slot. Qt will indeed call directly the function pointer of the slot, andwill not need moc introspection anymore. (It still needs it for the signal)
But what we can also do is connecting to any function or functor:
This can become very powerful when you associate that with boost or tr1::bind.
C++11 lambda expressions
Everything documented here works with the plain old C++98. But if you use compiler that supportsC++11, I really recommend you to use some of the language's new features.Lambda expressions are supportedby at least MSVC 2010, GCC 4.5, clang 3.1. For the last two, you need to pass -std=c++0x asa flag.
You can then write code like:
This allows you to write asynchronous code very easily.
Update: Also have a look what other C++11 features Qt5 offers.
Qt Connect Signal Slot Different Class
It is time to try it out. Check out the alpha and start playing. Don't hesistate to report bugs.
