Question

Qt is a nice framework and great UI toolkit and it has many useful features and concepts. Most of us probably agree that Trolltech, lately Nokia, have done pretty nice job developing it. One of the latest advances in Qt is QML, which I find fascinating advancement.

However, I find some of the concepts badly designed or badly implemented, such as Model/View (the concept is fine, but implementation is not) and same goes for Phonon media framework. Some people say its the meta-object concept that drives them crazy.

All of this are obviously more or less subjective, but what features or concepts do you find annoying or burdensome to use in Qt and how do you circumvent around them?

Answer 1

Most of my gripes with Qt come from the fact that the API does not fully embrace the dynamism provided by QObject. If you dared to create a meta-object compiler to add dynamic behavior to C++, why be shy about it, then?

All the stuff I list below are things my team needed at some point and we had to code it ourselves. It was a lot of fun and we learned a lot about the Qt internals, but I wouldn’t mind if it was already done and ready to use.

No Distributed QObject

You know, like in Cocoa. They went half way with QtDBus — the only thing left to do is the networking. We had to implement our own solution for this, and since we live outside the Qt code, we cannot change internals to implement all nice features.

No API for data storage

And of course everyone writes their own incomplete QObject-to-SQLite library. QDataStream is a very good beginning, though.

No Data Binding

Well, Qt Quick has data binding, but data binding should live in QtCore. With decent data binding, writing QAbstractItemModels that represent collections of QObjects should be a thing of the past: QObjectListModel should be all you need.

(Yeah, QDataWidgetMapper is a joke.)

No Automatic Undo Management for QObjects

Our model classes are usually QObjects and Q_PROPERTY has an optional NOTIFY signal that is exactly what is needed to implement automatic undo. It’s so easy to do it should already be part of Qt. (It requires a few kludges, however.)

No Collection Properties

Not all properties are born equal. Some of them are collections. Being able to deal with those in an abstract way would be definitely a good thing.

Half-baked QMetaStuff API

And I only hate this API because I love it. For instance, one cannot:

1. build QMetaObjects dynamically and replace them;
2. call a meta-method using a QVariants as arguments;
3. query methods by return type, name, or argument types;
4. connect signals and slots using the respective QMetaMethods (at least not until 4.8);
5. intercept property set/get in the same way you can intercept events, for instance.

Almost all of those can be worked around easily. A solution for #2:

QVariant call(QObject* object, QMetaMethod metaMethod, QVariantList args)
{
    QList<QGenericArgument> arguments;

    for (int i = 0; i < args.size(); i++) {

        // Notice that we have to take a reference to the argument. A 
        // const_cast is needed because calling data() would detach 
        // the QVariant.

        QVariant& argument = args[i];

        QGenericArgument genericArgument(
            QMetaType::typeName(argument.userType()),
            const_cast<void*>(argument.constData())
        );

        arguments << genericArgument;
    }

    QVariant returnValue(QMetaType::type(metaMethod.typeName()), 
        static_cast<void*>(NULL));

    QGenericReturnArgument returnArgument(
        metaMethod.typeName(),
        const_cast<void*>(returnValue.constData())
    );

    // Perform the call

    bool ok = metaMethod.invoke(
        object,
        Qt::AutoConnection, // In case the object is in another thread.
        returnArgument,
        arguments.value(0),
        arguments.value(1),
        arguments.value(2),
        arguments.value(3),
        arguments.value(4),
        arguments.value(5),
        arguments.value(6),
        arguments.value(7),
        arguments.value(8),
        arguments.value(9)
    );

    if (!ok) {
        // Handle the error...
    } else {
        return returnValue;
    }
}

Useful features will probably be removed

There is talk in qt-interest that the DOM, style sheets, and custom file engines will be removed in a future version of Qt.

Phonon has no cross-platform back-end

Besides not really working all the time, Phonon has no stable back-end that works on the three most common platforms: Windows, Linux and Mac OS X. There is a VLC back-end, but it’s definitely not stable, its licensing is unclear and, moreover, VLC support for Mac is “resting on shaky ground“. The blame is entirely on Linux, of course. Multimedia support has never been one of its strengths. It lacks something like Quicktime or the DirectStuff.

No Crypto Classes

There is QCryptographicHash and QSSLSocket (and its funny error modes), and that’s it. Fortunately, there are two good libraries to fill this gap: Botan and QCA. QCA is based on Qt, but copies its API from the Java crypto classes so, not very good. Botan has a nifty interface and (but?) is “pure” C++. A Qt-style crypto library is still lacking.