view doc/cmd-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 1ca49b349037
children
line wrap: on
line source

/** @page cmd-signals Command Signals
  @signals
  	@signal cmd-added
	@signal cmd-removed
  @endsignals

  @see cmds.h

  @signaldef cmd-added
  	@signalproto
void (*cmd_added)(const char *command, PurpleCmdPriority priority,
                  PurpleCmdFlag flag);
	@endsignalproto
	@signaldesc
	 Emitted when a new command is added.
	@param command   The new command.
	@param priority  The priority of the new command.
	@param flag      The command flags.
  @endsignaldef

  @signaldef cmd-removed
  	@signalproto
void (*cmd_removed)(const char *command);
	@endsignalproto
	@signaldesc
	 Emitted when a command is removed.
	@param command   The removed command.
  @endsignaldef
*/