I'm working mostly on Qt for S60 environment, so some of the issues are specific for that platform.
Plugin system + QObjects
You cannot declare plugin interface with signals, because the plugin implementations are supposed to derive from QObject and multiple interfaces, so the interface shouldn't be QObject itself (required if you want some signals in your interface). The workaround I found on Qt-interest mailing list is adding a MyQObject* getter to your plugin interface and adding all signals to concrete MyQObject class. It works, but it's counterintuitive and ugly.
QSet and other Qt containers are less versatile than stl or boost containers
For example you can't define less function that should be used when inserting elements into QSet. Other stuff I miss is remove_if and find_if.
QServiceFramework in QtMobility package
Ridiculous library I was recently forced to use. To use a "service" installed in QServiceFramework you either have to link to dll which contains that service (which is quite pointless, considering that one of the QSf goals is to hide dependencies) or use QMetaObject::invokeMethod that doesn't provide compile-time checking of methods, argument types, etc. and reduces code readability:
// using QMetaObject::invokeMethod
QVariantHash data;
bool ok = QMetaObject::invokeMethod(myObject, "getStuff",
Q_RETURN_ARG(QVariantHash, data)
Q_ARG(QString, QString("blah")));
Q_ASSERT(ok);
// using normal syntax
QVariantHash data(myObject->getStuff("blah"));
To make things worse, it uses file system quite a lot (iterating dirs looking for plugins, communication with SQLite database), which is a slow operation on S60.
QPixmap requires QApplication...
...and only QPixmap have methods for conversion between native S60 images (CFbsBitmap class) and Qt data. So you either have to make your
answered 2010-09-08T10:55:08.130