If I change the state of my presence the signal "PresencesChanged()" is not sent immediately. It seems that something blocks it until the connection is closed. After disconnecting, the events are delivered to me. Changes of the presence of my contacts are received immediately.
The TelepathyQt4 library does no processing, queuing or anything else to emissions of that signal, in fact nothing in the library itself is connected to the signal. The signal simply is declared in the proxy class for QtDBus to match signals received over DBus against, and you getting the signals otherwise indicates the signal is declared correctly. Are you sure you are returning to the Qt event loop properly while waiting for the signal to happen? (or running a separate QEventLoop?) Other such simple issues? Otherwise, the problem likely lies in service space (in the Gabble/TpPresenceMixin implementation). Of course, a weird QtDBus bug might be a cause, but as QtDBus doesn't in any way unpack complex types (such as the PresencesChanged arguments), I can't see any way it could possibly handle signal emissions in a different fashion in different cases. In any case, cannot be a bug in TelepathyQt4. Tracking up the problem should be started with running your application with QDBUS_DEBUG=2 ./yourapp, running dbus-monitor, and possibly also running the Telepathy connection manager with debugging enabled (for Gabble, do GABBLE_DEBUG=all telepathy-gabble). That way you can see where in the chain the event is lost.
Actually, I'm now confident that the bug is indeed in QtDBus. I ran into a similar problem today in one of my tests for the Group interface autointrospection, where I only got the reply to a Properties.GetAll call once something else (for example, a group flags change) happened on DBus. Until that, QtDBus seemed not to notice the reply at all (judging from the log). Probably a short read / queue unload issue. I'll look into it.
Actually, I'm now confident that the bug is indeed in QtDBus. I ran into a similar problem today in one of my tests for the Group interface autointrospection, where I only got the reply to a Properties.GetAll call once something else (for example, a group flags change) happened on DBus. Until that, QtDBus seemed not to notice the reply at all (judging from the log). Probably a short read / queue unload issue. I'll look into it together with Thiago.
Ah, forgot to comment here. Bug fix (utilising dbus_connection_set_dispatch_status_function) has been submitted to Trolltech already. The patch is at http://people.collabora.co.uk/~oggis/qdbus-use-dispatch-status-function.patch for anyone interested. I'm not sure if it's in Qt snapshots yet though.
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.