| Home | All Classes | Main Classes | Annotated | Grouped Classes | Functions | |
Signals and slots are used for communication between objects. The signal/slot mechanism is a core technology of smooth and probably the part that differs most from other toolkits. smooth is probably the only object oriented toolkit that supports signals and slots without the need of an additional preprocessor.
In GUI programming we often want a change in one widget to be notified to another widget. More generally, we want objects of any kind to be able to communicate with one another. For example if we were parsing an XML file we might want to notify a list view that we're using to represent the XML file's structure whenever we encounter a new tag.
Older toolkits and older versions of smooth achieve this kind of communication using callbacks. A callback is a pointer to a function, so if you want a processing function to notify you about some event you pass a pointer to another function (the callback) to the processing function. The processing function then calls the callback when appropriate. Callbacks have two fundamental flaws. Firstly they are not type safe. We can never be certain that the processing function will call the callback with the correct arguments. Secondly the callback is strongly coupled to the processing function since the processing function must know which callback to call.
Old-fashioned callbacks impair component programming
In smooth we have an alternative to the callback technique. We use signals and slots. A signal is emitted when a particular event occurs. smooth's widgets have many pre-defined signals, but we can always subclass to add our own. A slot is a function that is called in reponse to a particular signal. smooth's widgets have many pre-defined slots, but it is common practice to add your own slots so that you can handle the signals that you are interested in.
Signals and Slots facilitate true type-safe component programming
The signals and slots mechanism is type safe: the signature of a signal must match the signature of the receiving slot. (In fact a slot taking zero arguments can be connected to any signal because it can ignore extra arguments.) Since the signatures are compatible, the compiler can help us detect type mismatches. Signals and slots are loosely coupled: a class which emits a signal neither knows nor cares which slots receive the signal. smooth'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. Signals and slots can take up to eight arguments of any type (extending smooth for using signals with more arguments is easy, though). They are completely typesafe: no more callback core dumps!
smooth continues to support callbacks, though, but it implements them in a typesafe manner. There are some cases where callbacks are more useful than signals. If you want to be sure that only one function is connected to an event or you want to receive a return value from a function, you probably want to use callbacks rather than signals.
All classes in smooth can contain signals and slots. Signals are emitted by objects when they change their state in a way that may be interesting to the outside world. 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.
Slots can be used for receiving signals, but they are normal member functions. A slot does not know if it has any signals connected to it. Again, the object does not know about the communication mechanism and can be used as a true software component.
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 desire. 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.
A minimal C++ class declaration might read:
class Foo
{
public:
Foo();
int value() const { return val; }
void setValue( int );
private:
int val;
};
A small smooth class might read:
class Foo
{
public:
Foo();
int value() const { return val; }
slots:
void setValue( int );
signals:
Signal1<int> valueChanged;
private:
int val;
};
This class has the same internal state, and public methods to access the state, but in addition it has support for component programming using signals and slots: this class can tell the outside world that its state has changed by emitting a signal, valueChanged(), and it has a slot which other objects may send signals to.
Slots are implemented by the application programmer. Here is a possible implementation of Foo::setValue():
void Foo::setValue( int v )
{
if ( v != val ) {
val = v;
valueChanged.Emit(v);
}
}
The line valueChanged.Emit(v) emits the signal valueChanged from the object. As you can see, you emit a signal by using signal.Emit(arguments).
Here is one way to connect two of these objects together:
Foo a, b;
a.valueChanged.Connect(&Foo::setValue, &b);
b.setValue( 11 ); // a == undefined b == 11
a.setValue( 79 ); // a == 79 b == 79
b.value();
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 been connected to b's valueChanged() signal, nothing happens (the signal disappears).
Note that the setValue() function sets the value and emits the signal only if v != val. This prevents infinite looping in the case of cyclic connections (e.g. if b.valueChanged() were connected to a.setValue()).
This example illustrates that objects can work together without knowing each other, as long as there is someone around to set up a connection between them initially.
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.
A list box, for example, emits both onHighlightEntry and onActivate signals. Most objects will probably only be interested in onActivate but some may want to know about which item in the list box is currently highlighted. If the signal is interesting to two different objects you just connect the signal to slots in both objects.
When a signal is emitted, the slots connected to it are executed immediately, just like a normal function call. The signal/slot mechanism is totally independent of any GUI event loop. The Emit() will return when all slots have returned.
If several slots are connected to one signal, the slots will be executed one after the other, in an arbitrary order, when the signal is emitted.
Signals can never have return types (i.e. Emit() never returns a value).
A slot is called when a signal connected to it is emitted. Slots are normal C++ functions and can be called normally; signals can be connected to any function in smooth, even normal C functions.
Since slots are normal member functions, they have access rights like ordinary member functions.
You can also define slots to be virtual, which we have found quite useful 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 the increased flexibility they provide, although the difference for real applications is insignificant. In general, emitting a signal that is connected to some slots, is approximately ten times slower than calling the receivers directly, with non-virtual function calls. This is the overhead required to locate the connection object, to iterate over all connections and to marshall any parameters in a generic fashion. While ten non-virtual function calls may 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 a very small proportion of the complete function call costs. The same is true whenever you do a system call in a slot - or indirectly call more than ten functions. The simplicity and flexibility of the signals and slots mechanism is well worth the overhead, which your users won't even notice.
| Copyright © 2002-2004 Robert Kausch | smooth homepage | smooth alpha documentation
|