Archive for April, 2009

Qt Meta-Object System and namespaces


In my recent work in KTutorial (implementing scripted tutorials using Kross) I stumbled upon some problems with Qt Meta-Object system and namespaces that I think are worth mentioning.

Note that these comments apply to Qt 4.5.1. In newer versions the described behaviour may be different (and, in the case of the bug, hopefully it will be already fixed it is fixed in Qt 4.5.3.).

The first is more something to take into account than a problem. When a signal or slot is connected (using QObject::connect directly, or indirectly, for example, through QSignalSpy) the types of the arguments should be qualified using the same namespace used in the signal or slot declaration. You may declare it with the class name alone, without namespace, but only if you always use connect with the class name alone. That is, you always use the namespace, or you never use the namespace, but you can’t mix it.

The second, a strange behaviour if you don’t know what’s going on, involves namespaces in signal signatures, QSignalSpy and QVariant. A perfect mix. QSignalSpy is a useful class from QtTest module that can be used to record the emissions for a signal of an object. The arguments are stored as QVariant objects, that act as general containers for data types.

By default, QVariant supports most of Qt data types, but it can also store other types once they are registered. After using Q_DECLARE_METATYPE macro, a type can be stored in a QVariant (provided it has a public default constructor, public copy constructor and public destructor, which holds true for pointers to any type). Without it, the code won’t even compile.

However, when the type is used in the argument of a signal spied by a QSignalSpy, the type must be also registered using qRegisterMetaType. If not done, it complaints in debug output at runtime with “Don’t know how to handle ‘scripting::ScriptedTutorial*’, use qRegisterMetaType to register it.”.

The strange behaviour comes into play when namespaces are added to the party. If a signal has an argument that is a type (or a pointer to a type) in a namespace, as said above you can declare the argument with the class name alone. If the type is registered with Q_DECLARE_METATYPE and qRegisterMetaType (with the class name alone, without namespace), QSignalSpy will record the emitted signals, and when the QVariant that stored the argument is queried for the userType(), it will even return the same id as qRegisterMetaType returned when the argument type was registered. Apparently, it works.

However, there is no way to get the value of the argument. When a qvariant_cast is used on the QVariant that stores the argument, a default constructed value is returned. That doesn’t mean that the argument can’t be sent in a signal. If it was connected to a slot, it would have received the true argument value. But qvariant_cast doesn’t know how to manage the argument type.

Why? Because, for qvariant_cast, the class name, and the class name qualified with the namespace are different types. When the type is declared using Q_DECLARE_METATYPE, internally the full qualified name is used. If the name registered in qRegisterMetaType doesn’t includes the namespace, it won’t be recognized by qvariant_cast. So the full qualified name must be used in qRegisterMetaType. And if this is done, the full qualified name must be used also in QSignalSpy, and therefore in the declaration of the signal. So, to sum up: use the full qualified name of classes in signals and slots, you’ll live longer and happier 😛

See testSetup() method for an example of all this in KTutorial commit #48.

The last is a true problem, as it is an already reported bug (246221 – QMetaObject::newInstance() returns 0 for class in namespace (as it is an old bug, it seems to be no longer online)). The QMetaObject::newInstance method, introduced in Qt 4.5, doesn’t work when the class is in a namespace. The problem seems to be that when the constructor signature is prepared in newInstance code it includes the namespace. However, indexOfConstructor method doesn’t use the namespace, so when the constructor is looked for it isn’t found and no new instance is created. The bug is fixed in Qt 4.5.3.