changeset 24771:8fb78d30ea83

We have a prpl function "buddy_free" that I don't think any of our in-tree prpls use, and it wasn't called from anywhere. But the facebook prpl uses it to free data associated with each buddy. I think it makes sense to call this function. In the future it would probably be cleaner to have prpls attach to a signal or something.
author Mark Doliner <mark@kingant.net>
date Thu, 18 Dec 2008 02:03:20 +0000
parents 22fd7467f0cc
children a0b89076a163 d265a11c6446 a959b17ffc57
files libpurple/blist.c
diffstat 1 files changed, 11 insertions(+), 0 deletions(-) [+]
line wrap: on
line diff
--- a/libpurple/blist.c	Thu Dec 18 01:53:49 2008 +0000
+++ b/libpurple/blist.c	Thu Dec 18 02:03:20 2008 +0000
@@ -1810,6 +1810,8 @@
 	PurpleContact *contact;
 	PurpleGroup *group;
 	struct _purple_hbuddy hb;
+	PurplePlugin *prpl;
+	PurplePluginProtocolInfo *prpl_info;
 
 	g_return_if_fail(buddy != NULL);
 
@@ -1865,6 +1867,15 @@
 	/* Signal that the buddy has been removed before freeing the memory for it */
 	purple_signal_emit(purple_blist_get_handle(), "buddy-removed", buddy);
 
+	/*
+	 * Tell the owner PRPL that we're about to free the buddy so it
+	 * can free proto_data
+	 */
+	prpl = purple_find_prpl(purple_account_get_protocol_id(buddy->account));
+	prpl_info = PURPLE_PLUGIN_PROTOCOL_INFO(prpl);
+	if (prpl_info && prpl_info->buddy_free)
+		prpl_info->buddy_free(buddy);
+
 	/* Delete the node */
 	purple_buddy_icon_unref(buddy->icon);
 	g_hash_table_destroy(buddy->node.settings);