Proposed attention API
seanegan at gmail.com
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 gmail.com <shellreef at gmail.com> 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
> 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
> http://msimprpl.darkthoughts.net/attention1.diff . The full patch,
> including all changes to msimprpl to use this new API, is at
> http://msimprpl.darkthoughts.net/attention1-full.diff (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:
> http://pidgin.im/pipermail/devel/2007-August/002468.html) would be the
> next logical step.
> Devel mailing list
> Devel at pidgin.im
More information about the Devel