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:
- build QMetaObjects dynamically and replace them;
- call a meta-method using a QVariants as arguments;
- query methods by return type, name, or argument types;
- connect signals and slots using the respective QMetaMethods (at least not until 4.8);
- 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 < argumentList.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.