We've been assuming in telepathy-spec design, in at least a few places, that longer-than-default method timeouts are possible; this makes it possible to implement RequestContactList() on Conn.I.ContactList and RequestContactInfo on Conn.I.ContactInfo, for instance. However, telepathy-qt4 doesn't allow this. On closer inspection, this is really a QtDBus bug - QDBusAbstractInterface::asyncCall and friends can't set a non-default timeout either! It might be possible to work around this with QDBusConnection::callWithCallback for the few places where we need it. I think the long-term solution would be for QtDBus to gain this optional argument: QDBusPendingCall QDBusAbstractInterface::asyncCallWithArgumentList (const QString &method, const QList<QVariant> &args, int timeout = -1); (Requiring construction of a QList<QVariant> for the unusual case is no big deal, IMO.)
The underlying bug is http://bugreports.qt.nokia.com/browse/QTBUG-11775
Due to C++ actually having optional parameters I'd really not do this on a case-by-case basis, but make the codegen emit that param in all generated proxy methods. Actually, how would it even be done case-by-case? Having an extra spec annotation for "it might take a while"? A blacklist of forever-taking methods in tp-qt4 codegen? That is, the only methods we have calling asyncCall are the auto-generated proxy D-Bus method wrappers - so any case-by-case handling would require feeding this case information somehow to the codegen. Anyway, we'll make 0.5.0 have a timeout parameter with a default argument in the methods for forwards-compatibility, documented as being ignored until QDBus gains support for it.
Fix merged to master. Will be in 0.5.0.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.