Mercurial > pidgin.yaz
view doc/imgstore-signals.dox @ 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 | e0613cf8c493 |
children |
line wrap: on
line source
/** @page imgstore-signals Image Store Signals @signals @signal image-deleting @endsignals @see imgstore.h <hr> @signaldef image-deleting @signalproto char *(*image_deleting)(const PurpleStoredImage *img); @endsignalproto @signaldesc Emitted when a #PurpleStoredImage is about to be destroyed. This allows for what amounts to weak references. Code can hold onto a pointer to the PurpleStoredImage without actually "holding" a reference. They can then use a signal handler to let them know when their img is about to be destroyed. @param img The image about to be destroyed. @note It's not possible to purple_imgstore_ref() img to save it. @endsignaldef */ // vim: syntax=c.doxygen tw=75 et