GNOME Bugzilla – Bug 632550
Continue killing EmpathyDispatcher
Last modified: 2011-08-29 10:12:43 UTC
As part of my work on bug #631946 I continued killing EmpathyDispatcher.
Created attachment 172714 [details] [review] http://git.Collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/kill-dispatcher-632550 libempathy/empathy-dispatcher.c | 124 --------------------------------------- libempathy/empathy-dispatcher.h | 6 -- libempathy/empathy-ft-handler.c | 78 ++++++++++++++++++------- libempathy/empathy-tp-chat.c | 24 ++++---- src/empathy-chat-manager.c | 8 ++- src/empathy-event-manager.c | 4 + 6 files changed, 79 insertions(+), 165 deletions(-)
Review of attachment 172714 [details] [review]: ::: libempathy/empathy-ft-handler.c @@ +1067,2 @@ value = tp_asv_get_uint32 + (fixed, TP_IFACE_CHANNEL_TYPE_FILE_TRANSFER ".ContentHashType", Use TP_PROP_CHANNEL_TYPE_FILE_TRANSFER_CONTENT_HASH_TYPE @@ +1243,3 @@ + + tp_proxy_prepare_async (connection, features, + conn_prepared_cb, cb_data); Why not request the CAPABILITIES feature in the TpBaseClient like you do for the Approver and Chat handler?
(In reply to comment #2) > Review of attachment 172714 [details] [review]: > > ::: libempathy/empathy-ft-handler.c > @@ +1067,2 @@ > value = tp_asv_get_uint32 > + (fixed, TP_IFACE_CHANNEL_TYPE_FILE_TRANSFER ".ContentHashType", > > Use TP_PROP_CHANNEL_TYPE_FILE_TRANSFER_CONTENT_HASH_TYPE Good point; done. > @@ +1243,3 @@ > + > + tp_proxy_prepare_async (connection, features, > + conn_prepared_cb, cb_data); > > Why not request the CAPABILITIES feature in the TpBaseClient like you do for > the Approver and Chat handler? Because we get the connection from the contact and so the connection is not prepared by TpBaseClient so we can't be sure that the feature has been prepared. Actually I *think* it is as the contact factory prepares the feature capabilities on contacts which will prepare the feature on the connection but that's pretty subtil so I prefer to make it more explicit. tp_proxy_prepare_async() is cheap is the feature is already prepared any way.
(In reply to comment #3) > Because we get the connection from the contact and so the connection is not > prepared by TpBaseClient so we can't be sure that the feature has been > prepared. Actually I *think* it is as the contact factory prepares the feature > capabilities on contacts which will prepare the feature on the connection but > that's pretty subtil so I prefer to make it more explicit. > tp_proxy_prepare_async() is cheap is the feature is already prepared any way. Ok. I'm happy.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.