diff libpurple/blist.c @ 27556:cbee8aecc90a

Free the buddy list data some more at shutdown and some deprecations. I think these deprecations are reasonable. Basically, purple_blist_init should create a PurpleBuddyList*, so each UI doesn't need to do that. The UI data for the PurpleBuddyList is more tightly coupled with the PurpleBuddyList and purple_blist_destroy is called in purple_blist_uninit (and is fully cleaned up now). As libpurple works currently, I believe it's not really possible to have multiple PurpleBuddyLists around (blist.c relies on a single global variable) and when it was discussed on the mailing list a few months ago, nobody was using it as such. Refs #9253 (going to milestone 3.0.0 it).
author Paul Aurich <paul@darkrain42.org>
date Sun, 12 Jul 2009 02:55:36 +0000
parents 75acd9ad14be
children 3bb1085235d0
line wrap: on
line diff
--- a/libpurple/blist.c	Sat Jul 11 21:53:52 2009 +0000
+++ b/libpurple/blist.c	Sun Jul 12 02:55:36 2009 +0000
@@ -3105,6 +3105,8 @@
 		purple_blist_sync();
 	}
 
+	purple_blist_destroy();
+
 	node = purple_blist_get_root();
 	while (node) {
 		next_node = node->next;
@@ -3112,10 +3114,14 @@
 		node = next_node;
 	}
 	purplebuddylist->root = NULL;
-	
+
 	g_hash_table_destroy(purplebuddylist->buddies);
 	g_hash_table_destroy(buddies_cache);
 
+	PURPLE_DBUS_UNREGISTER_POINTER(purplebuddylist);
+	g_free(purplebuddylist);
+	purplebuddylist = NULL;
+
 	purple_signals_disconnect_by_handle(purple_blist_get_handle());
 	purple_signals_unregister_by_instance(purple_blist_get_handle());
 }