[Development] Some Qt3D feedback

Simon Hausmann simon.hausmann at theqtcompany.com
Thu Jun 18 13:19:24 CEST 2015


On Thursday, June 18, 2015 12:45:53 PM Marc Mutz wrote:
[...]
> The meta-type system and moc are perfectly fine with namespaces. If people
> would just peek over their own noses and over to your cousin, KDE, you'd see
> that, say, kdepimlibs would have a very hard time indeed, if QMetaType or
> moc would have any trouble with namespaces whatsoever.

Let me give you a concrete example of where "no trouble whatsoever" does not 
hold in my opinion:

Qt3D has a QKeyboardInput class:

namespace Qt3D {

class QKeyboardInput: public QComponent
{
    ...
Q_SIGNALS:
    void leftPressed(Q3DKeyEvent *event);
    ...
};

The Q3DKeyEvent class is declared in a namespace as well:

namespace Qt3D {
class Q3DKeyEvent : public QObject
{
    ...
};
}

The moc generated code for QKeyboardInput stores "Q3DKeyEvent*" as
type name for the parameter of the leftPressed signal.

When connecting to this signal using the traditional SIGNAL/SLOT syntax,
a string comparison takes place to ensure that the types match. This means two
things for a signal-slot connection to work:

1) The signature of the slot that connects to the signal has either ignore the 
parameter or it has to be qualified exactly like in the signal declaration, in 
order for the connect() call to work. You cannot simply use this:

class MyReceiver : public QObject
{
    ...
Q_SLOTS:
    void turnLeft(Qt3D::Q3DKeyEvent *event);
};

2) In addition if the parameter was _not_ prefixed but was merely called 
"KeyEvent", then the following code would allow for connections to be 
established, but it would crash at run-time - eliminating the type-safety of 
signal and slot connections:

struct KeyEvent {
    ...
}

class MyReceiver : public QObject
{
    ...
Q_SLOTS:
    void turnLeft(KeyEvent *event);
};



Simon



More information about the Development mailing list