GNOME Bugzilla – Bug 663682
remove EmpathyTpFile
Last modified: 2011-11-29 14:59:53 UTC
http://cgit.freedesktop.org/~jonny/empathy/log/?h=ft Here's a branch to do just that. Unfortunately it can't be merged yet as my tp-glib changes to add Provide/Accept implementations to TpFTChannel haven't been merged or released yet but I thought I'd just get on and do it. See https://bugs.freedesktop.org/show_bug.cgi?id=39188 for the tp-glib bug. I tried to split up the patches as much as possible but some were bigger than I'd have hoped.
Created attachment 201142 [details] [review] libempathy: remove empathy-tp-file from headers This is just a little hack so GEnums aren't created for enums in empathy-tp-file.h. We'll remove the files in a sec but I want to try and avoid breaking bisect. Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
Created attachment 201143 [details] [review] ft-handler: start using TpFTChannel instead of EmpathyTpFile Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
Created attachment 201144 [details] [review] client-factory: stop creating EmpathyTpFile objects TpAutomaticClientFactory will create TpFileTransferChannels for us and they're, like, way better. Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
Created attachment 201145 [details] [review] tp-file: remove EmpathyTpFile TpFTChannel! Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
Review of attachment 201142 [details] [review]: ++
Review of attachment 201143 [details] [review]: ::: libempathy/empathy-ft-handler.c @@ +266,3 @@ + if (priv->channel != NULL) { + tp_channel_close_async (TP_CHANNEL (priv->channel), NULL, NULL); channel_closed_cb in tp-file is doing some extra work to cancel the cancellable, if needed. Can we safely miss that? @@ +1516,3 @@ g_cancellable_cancel (priv->cancellable); else + tp_channel_close_async (TP_CHANNEL (priv->channel), NULL, NULL); same question as above regarding the cancellable.
Review of attachment 201144 [details] [review]: ++
Review of attachment 201145 [details] [review]: ++ assuming "make check" passes.
For some value of "accepted-commit_now" meaning "commit once the tp-glib bits have been released and we depend on the right tp-glib version" :)
(In reply to comment #6) > Review of attachment 201143 [details] [review]: > > ::: libempathy/empathy-ft-handler.c > @@ +266,3 @@ > > + if (priv->channel != NULL) { > + tp_channel_close_async (TP_CHANNEL (priv->channel), NULL, NULL); > > channel_closed_cb in tp-file is doing some extra work to cancel the > cancellable, if needed. Can we safely miss that? > > @@ +1516,3 @@ > g_cancellable_cancel (priv->cancellable); > else > + tp_channel_close_async (TP_CHANNEL (priv->channel), NULL, NULL); > > same question as above regarding the cancellable. Yes, the cancellable is still present and will be cancelled when the channel is invalidated (or when the proxy is disposed).
(In reply to comment #9) > For some value of "accepted-commit_now" meaning "commit once the tp-glib bits > have been released and we depend on the right tp-glib version" :) Groovy, thanks!
(In reply to comment #10) > (In reply to comment #6) > > Review of attachment 201143 [details] [review] [details]: > > > > ::: libempathy/empathy-ft-handler.c > > @@ +266,3 @@ > > > > + if (priv->channel != NULL) { > > + tp_channel_close_async (TP_CHANNEL (priv->channel), NULL, NULL); > > > > channel_closed_cb in tp-file is doing some extra work to cancel the > > cancellable, if needed. Can we safely miss that? > > > > @@ +1516,3 @@ > > g_cancellable_cancel (priv->cancellable); > > else > > + tp_channel_close_async (TP_CHANNEL (priv->channel), NULL, NULL); > > > > same question as above regarding the cancellable. > > Yes, the cancellable is still present and will be cancelled when the channel > is invalidated (or when the proxy is disposed). I see; works for me then!
Is this branch still blocked?
Merged to master /o/ 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.