/**************************************************************************** ** ** Explanation of tqmoc and the meta object system ** ** Copyright (C) 1992-2008 Trolltech ASA. All rights reserved. ** ** This file is part of the TQt GUI Toolkit. ** ** This file may be used under the terms of the GNU General ** Public License versions 2.0 or 3.0 as published by the Free ** Software Foundation and appearing in the files LICENSE.GPL2 ** and LICENSE.GPL3 included in the packaging of this file. ** Alternatively you may (at your option) use any later version ** of the GNU General Public License if such license has been ** publicly approved by Trolltech ASA (or its successors, if any) ** and the KDE Free TQt Foundation. ** ** Please review the following information to ensure GNU General ** Public Licensing requirements will be met: ** http://trolltech.com/products/qt/licenses/licensing/opensource/. ** If you are unsure which license is appropriate for your use, please ** review the following information: ** http://trolltech.com/products/qt/licenses/licensing/licensingoverview ** or contact the sales department at sales@trolltech.com. ** ** This file may be used under the terms of the Q Public License as ** defined by Trolltech ASA and appearing in the file LICENSE.QPL ** included in the packaging of this file. Licensees holding valid Qt ** Commercial licenses may use this file in accordance with the Qt ** Commercial License Agreement provided with the Software. ** ** This file is provided "AS IS" with NO WARRANTY OF ANY KIND, ** INCLUDING THE WARRANTIES OF DESIGN, MERCHANTABILITY AND FITNESS FOR ** A PARTICULAR PURPOSE. Trolltech reserves all rights not granted ** herein. ** **********************************************************************/ /*! \page signalsandslots.html \title Signals and Slots Signals and slots are used for communication between objects. The signal/slot mechanism is a central feature of TQt 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. 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 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. \img abstract-connections.png \caption An abstract view of some signals and slots connections In TQt we have an alternative to the callback technique. We use signals and slots. A signal is emitted when a particular event occurs. Qt'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. Qt'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. 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 may have a shorter signature than the signal it receives 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. Qt'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 any number of arguments of any type. They are completely typesafe: no more callback core dumps! All classes that inherit from TQObject or one of its subclasses (e.g. TQWidget) 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. \img concrete-connections.png \caption An example of signals and slots connections Slots can be used for receiving signals, but they are also normal member functions. 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. 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. \section1 A Small Example A minimal C++ class declaration might read: \code class Foo { public: Foo(); int value() const { return val; } void setValue( int ); private: int val; }; \endcode A small TQt class might read: \code class Foo : public TQObject { TQ_OBJECT public: Foo(); int value() const { return val; } public slots: void setValue( int ); signals: void valueChanged( int ); private: int val; }; \endcode 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, \c{valueChanged()}, and it has a slot which other objects can send signals to. All classes that contain signals or slots must mention TQ_OBJECT in their declaration. Slots are implemented by the application programmer. Here is a possible implementation of Foo::setValue(): \code void Foo::setValue( int v ) { if ( v != val ) { val = v; emit valueChanged(v); } } \endcode The line \c{emit valueChanged(v)} emits the signal \c{valueChanged} from the object. As you can see, you emit a signal by using \c{emit signal(arguments)}. Here is one way to connect two of these objects together: \code Foo a, b; connect(&a, TQ_SIGNAL(valueChanged(int)), &b, TQ_SLOT(setValue(int))); b.setValue( 11 ); // a == undefined b == 11 a.setValue( 79 ); // a == 79 b == 79 b.value(); // returns 79 \endcode Calling \c{a.setValue(79)} will make \c{a} emit a \c{valueChanged()} signal, which \c{b} will receive in its \c{setValue()} slot, i.e. \c{b.setValue(79)} is called. \c{b} will then, in turn, emit the same \c{valueChanged()} signal, but since no slot has been connected to \c{b}'s \c{valueChanged()} signal, nothing happens (the signal is ignored). Note that the \c{setValue()} function sets the value and emits the signal only if \c{v != val}. This prevents infinite looping in the case of cyclic connections (e.g. if \c{b.valueChanged()} were connected to \c{a.setValue()}). A signal is emitted for \e{every} connection you make, so if you duplicate a connection, two signals will be emitted. You can always break a connection using \c{TQObject::disconnect()}. This example illustrates that objects can work together without knowing about each other, as long as there is someone around to set up a connection between them initially. The preprocessor changes or removes the \c{signals}, \c{slots} and \c{emit} keywords so that the compiler is presented with standard C++. Run the \link tqmoc.html tqmoc\endlink on class definitions that contain signals or slots. This produces a C++ source file which should be compiled and linked with the other object files for the application. If you use \link qmake-manual.book qmake\endlink, the makefile rules to automatically invoke the \link tqmoc.html tqmoc\endlink will be added to your makefile for you. \section1 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 can emit the signal. A list box, for example, emits both \c{clicked()} and \c{currentChanged()} signals. Most objects will probably only be interested in \c{currentChanged()} which gives the current list item whether the user clicked it or used the arrow keys to move to it. But some objects may only want to know which item was clicked. 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 \c{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 are automatically generated by the \link tqmoc.html tqmoc\endlink and must not be implemented in the \c .cpp file. They can never have return types (i.e. use \c void). A note about arguments. Our experience shows that signals and slots are more reusable if they do \e not use special types. If \l TQScrollBar::valueChanged() were to use a special type such as the hypothetical \c TQRangeControl::Range, it could only be connected to slots designed specifically for TQRangeControl. Something as simple as the program in \link tutorial1-05.html Tutorial #1 part 5\endlink would be impossible. \section1 Slots A slot is called when a signal connected to it is emitted. Slots are normal C++ functions and can be called normally; their only special feature is that signals can be connected to them. A slot's arguments cannot have default values, and, like signals, it is rarely wise to use your own custom types for slot arguments. Since slots are normal member functions with just a little extra spice, they have access rights like ordinary member functions. A slot's access right determines who can connect to it: A \c{public slots} section contains slots that anyone can connect signals to. This is very useful for component programming: you create objects that know nothing about each other, connect their signals and slots so that information is passed correctly, and, like a model railway, turn it on and leave it running. A \c{protected slots} section contains slots that this class and its subclasses may connect signals to. This is intended for slots that are part of the class's implementation rather than its interface to the rest of the world. A \c{private slots} section contains slots that only the class itself may connect signals to. This is intended for very tightly connected classes, where even subclasses aren't trusted to get the connections right. 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 safely iterate over all connections (i.e. checking that subsequent receivers have not been destroyed during the emission) 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. On an i586-500, you can emit around 2,000,000 signals per second connected to one receiver, or around 1,200,000 per second connected to two receivers. The simplicity and flexibility of the signals and slots mechanism is well worth the overhead, which your users won't even notice. \section1 Meta Object Information The meta object compiler (\link tqmoc.html tqmoc\endlink) parses the class declaration in a C++ file and generates C++ code that initializes the meta object. The meta object contains the names of all the signal and slot members, as well as pointers to these functions. (For more information on Qt's Meta Object System, see \link templates.html Why doesn't TQt use templates for signals and slots?\endlink.) The meta object contains additional information such as the object's \link TQObject::className() class name\endlink. You can also check if an object \link TQObject::inherits() inherits\endlink a specific class, for example: \code if ( widget->inherits("TQButton") ) { // yes, it is a push button, radio button etc. } \endcode \section1 A Real Example Here is a simple commented example (code fragments from \l tqlcdnumber.h ). \code #include "tqframe.h" #include "tqbitarray.h" class TQLCDNumber : public TQFrame \endcode TQLCDNumber inherits TQObject, which has most of the signal/slot knowledge, via TQFrame and TQWidget, and #include's the relevant declarations. \code { TQ_OBJECT \endcode TQ_OBJECT is expanded by the preprocessor to declare several member functions that are implemented by tqmoc; if you get compiler errors along the lines of "virtual function TQButton::className not defined" you have probably forgotten to \link tqmoc.html run tqmoc\endlink or to include tqmoc output in the link command. \code public: TQLCDNumber( TQWidget *parent=0, const char *name=0 ); TQLCDNumber( uint numDigits, TQWidget *parent=0, const char *name=0 ); \endcode It's not obviously relevant to tqmoc, but if you inherit TQWidget you almost certainly want to have the \e{parent} and \e{name} arguments in your constructors, and pass them to the parent constructor. Some destructors and member functions are omitted here; tqmoc ignores member functions. \code signals: void overflow(); \endcode TQLCDNumber emits a signal when it is asked to show an impossible value. If you don't care about overflow, or you know that overflow cannot occur, you can ignore the overflow() signal, i.e. don't connect it to any slot. If, on the other hand, you want to call two different error functions when the number overflows, simply connect the signal to two different slots. TQt will call both (in arbitrary order). \code public slots: void display( int num ); void display( double num ); void display( const char *str ); void setHexMode(); void setDecMode(); void setOctMode(); void setBinMode(); void smallDecimalPoint( bool ); \endcode A slot is a receiving function, used to get information about state changes in other widgets. TQLCDNumber uses it, as the code above indicates, to set the displayed number. Since \c{display()} is part of the class's interface with the rest of the program, the slot is public. Several of the example programs connect the newValue() signal of a TQScrollBar to the display() slot, so the LCD number continuously shows the value of the scroll bar. Note that display() is overloaded; TQt will select the appropriate version when you connect a signal to the slot. With callbacks, you'd have to find five different names and keep track of the types yourself. Some irrelevant member functions have been omitted from this example. \code }; \endcode */