Mercurial > pidgin.yaz
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()); }