[Adium-devl] Proposed attention API
alan at ewonderz.com
Tue Aug 14 16:07:15 EDT 2007
I agree that the icons (if any) should live in the presentation app
and not in libpurple.
(I know that I'm stating the obvious, but I have to keep up my
reputation for being Mr. Obvious.)
The place where these image/library boundaries gets a bit blurred is
with items like Yahoo IMvironments or avatars which come from the
-- Alan Humpherys
Sent from my iPhone
On Aug 13, 2007, at 10:43 PM, shellreef at gmail.com wrote:
> n 8/13/07, Sean Egan <seanegan at gmail.com> wrote:
>> do we need an "icon" parameter?
> It is not used yet in msimprpl, but MySpaceIM has different icons for
> each of the zaps.
> Yahoo and MSN have icons as well, but they are only used in the button
> for sending attention requests. Maybe Pidgin could have icons
> representing buzz and nudge (or not).
> I could imagine a poking finger icon to represent the "poke" attention
> command in the hypothetical Facebook IM.
>> serv_got_attention(PurpleConnection *gc, const char *who,
>> PurpleAttentionType *attn, gboolean incoming)
>> Will this ever be called if the attention *isn't* incoming?
> I call it in msimprpl after the user sends an attention command and it
> should be displayed in the conversation window as being sent. I was
> thinking along the lines of how serv_got_im() has PURPLE_MESSAGE_RECV
> and PURPLE_MESSAGE_SEND. Both events are displayed similarly (and in
> some protocols, identically), so it makes sense to group them together
> in the same function.
> The outgoing attention command can't be displayed immediately when it
> is sent, because like an outgoing instant message, it may fail for
> some reason.
> For comparison, before I added the incoming flag I was manually
> writing "Sending zap to %s" to the conversation using serv_got_im()
> after the user sent a zap (and this is what I still do if msimprpl is
> compiled without the attention API). I think it is best if the client
> handles displaying that an attention command was sent, rather than the
>> 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.
> Here's what I was thinking about how each of the fields in
> PurpleAttentionType would be used:
> (note that with a stable attention API, zapping will be accessible in
> a more sensible place than the blist node menu - this is just a
> The problem with having a "const char *text" parameter is that the
> attention text isn't really free-form, in any of the protocols. At
> least in msimprpl, I'd have to search the list of attention commands
> that are valid in MySpaceIM, and translate the text to a valid
> protocol message. This isn't impossible, but it would be easier if an
> integer code was passed, that I could use to index into into a list
> with all the pertinent information on the attention command that is
> Having an integer parameter instead of a text parameter also makes it
> easy to send a generic attention command, if the protocol supports
> only one: just send zero. Compare:
> if (p->send_attention) p->send_attention(gc, username, 0);
> if (p->attention_types && p->send_attention)
> GList *types = p->attention_types(gc->account);
> p->send_attention(gc, username, (const char *)types->data);
> PurpleAttentionType *attn = g_list_nth_data(types, code);
> /* iterate over each of the attention commands - too long to write out
> here :) */
> So basically, it would mean more coding to use a string instead.
> We could pass NULL for the default attention command, but that
> requires special-casing NULL, when an index of 0 wouldn't need to be
> Also, it may be useful to have different tenses of the attention
> command. In the screenshot above, I have:
> 1) description - an action that the user can perform, for GUI
> elements ("zap")
> 2) incoming_description - past tense ("You have been zapped")
> 3) outgoing_description - present tense ("Zapping msimprpl")
> We could, of course, just have one term ("zap") and use it in all
> instances ("You have received a zap", "You have sent a zap") but I
> don't like that as much because it requires treating the action as a
> inanimate noun when it really should be an active, living, verb that
> actually does something. And it isn't trivial to conjugate verbs
> programmatically ("You have been X'd", "X'ing msimprpl") so I don't
> think we want to go there.
> What is the real cost of adding a new data type? I think it is an
> elegant solution, given the features that each of the protocols have
> in common.
> P.S.: Agreed about adding a new signal; it seems only logical.
> Something like this:
> plugin_return = GPOINTER_TO_INT(
> "receiving-im-attention", gc-
> &username, &attn, cnv, &flags));
> where attn is a PurpleAttentionType *, allowing plugins access to all
> of the fields described above. So they could process all attention
> commands, handle certain ones differently (by inspecting the 'code'
> field), or format the attention command for display to the user using
> the textual fields.
> And once the command is received:
> "received-im-attention", gc->account, name, attn)
> Adium-devl mailing list
> Adium-devl at adiumx.com
More information about the Devel