view doc/dbus-server-signals.dox @ 27480: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).

/** @page dbus-server-signals DBus Server Signals

 @signals
  @signal dbus-method-called
  @signal dbus-introspect
 @endsignals

 @see dbus-server.h

 <hr>

 @signaldef dbus-method-called
  @signalproto
gboolean (*dbus_method_called)(DBusConnection *connection,
                               DBusMessage *message);
  @endsignalproto
  @signaldesc
   Emitted when a dbus method is going to be called.
  @param connection The DBus connection.
  @param message The DBus message.
  @return TRUE if signal handler handled the method. ???
 @endsignaldef

 @signaldef dbus-introspect
  @signalproto
void (*dbus_introspect)(GList **bidings_list);
  @endsignalproto
  @signaldesc
   ???
  @param bindings_list ???
 @endsignaldef

 */
// vim: syntax=c.doxygen tw=75 et