Proposed attention API

Sean Egan seanegan at
Mon Aug 13 15:50:38 EDT 2007

Forwarding to adium-devl, as they're currently doing special case
hacks for this, and I'm sure they'd love a generalized solution. My
apologies to Ethan for top-posting.

do we need an "icon" parameter?

serv_got_attention(PurpleConnection *gc, const char *who,
PurpleAttentionType *attn, gboolean incoming)

Will this ever be called if the attention *isn't* incoming?

It seems like we shouldn't need an entire new object for this. Would
it be enough to have:

serv_got_attention(PurpleConnection *gc, const char *who, const char *text);

It looks like that's the only place that object is even used.

On 8/12/07, shellreef at <shellreef at> wrote:
> I committed a possible "attention" API to im.pidgin.soc.2007.msimprpl,
> in revision
> b888bc5c0494c9dd0398baba81e4d602ac88948f. Here is the commit message,
> explaining what it is all about:
>  Proposed "attention" API, a generalization of zaps (MySpaceIM), buzzes
>  (Yahoo), and nudges (MSN).
>  Adds a PurpleAttentionType struct to prpl.h, which is used to describe the
>  the attention command (some protocols, notably MySpaceIM, support more than
>  one).
>  Uses two reserved fields in PurplePluginProtocolInfo, one function for sending
>  an attention command, another for getting the possible attention commands
>  (similar to status_types).
>  Adds serv_got_attention() to server.c, similar to serv_got_im(), used to notify
>  of incoming or outgoing attention notices.
> A patch to libpurple is at
> . The full patch,
> including all changes to msimprpl to use this new API, is at
> (these are both
> in the same commit; unfortunately I mistakingly didn't commit each
> separately). The Yahoo and MSN prpls don't currently use the new API.
> What does everyone think of these changes?  I think we all can agree
> that a unified attention API is a good thing, but is the way I've done
> it a good way to do it? One thing I'm not sure about is the use of
> reserved fields in PurplePluginProtocolInfo, and how this change would
> impact libpurple's versioning.
> If everyone agrees with this change, UI additions to allow using this
> API (discussed in the thread starting here:
> would be the
> next logical step.
> Regards,
> -Jeff
> _______________________________________________
> Devel mailing list
> Devel at

More information about the Devel mailing list