view doc/imgstore-signals.dox @ 25977:0e93bbb7f5ca

Woo boy this function is a little crazy. I shuffled some things around: 1. We now call aim_srv_setextrainfo() after aim_locate_setprofile() This fixes the bug where, if you set an available message, then set an away message, then change your state to available but leave the same away message up, the AIM servers would use your old available message. I'm not really sure why it happens... maybe some sort of race condition in how the server parses our requests. In any case, this fixes it, and it's what the official clients seem to do (or AIM Lite at least) 2. Combine the code for stripping HTML and truncating the available message. It was happening in two places before (one for available messages and another for ICQ away messages) 3. Put our away message in the field we've been calling an "available" message. This seems to be what the official clients do. Or AIM Lite at least. I'm not sure if there will be other side effects.
author Mark Doliner <mark@kingant.net>
date Thu, 05 Mar 2009 23:54:50 +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