Revision f6a67901e79d8d35e6bf30f0766b2417740090b7

Evan Schoenberg evan.s at
Tue Aug 28 12:09:34 EDT 2007

On Aug 28, 2007, at 8:33 AM, Andreas Monitzer wrote:
> Nathan wrote:
>> Andreas wrote:
>>>> - forces buddy icons to PNGs, which will kill animated buddy icons
>>> XEP-0084 says that PNG is required. It's possible to specify
>>> multiple alternatives (at least one of them has to be PNG), but
>>> libpurple's API doesn't allow for that, so I had to force it to
>>> PNG only.
>>>> - the prpl now knows way too much about PNGs.  That functionality
>>>> should
>>>> be abstracted out to somewhere else, core or otherwise.
>>> Yes, knowing the image size would be great. I hope you understand
>>> that I hesitated rewriting the core API for my project.
>> Unfortunately, people get really cranky when their buddy icons
>> don't animate.
> That's news to me. Adium specifically checks for animated avatars and
> disallows them, and I haven't heard a single person complaining about
> that.

That's not true.

Adium specifically allows animated avatars, and quite a bit of effort  
went into making sure that it works.  The GIF format is given  
precedence over all others regardless of what libpurple specifies as  
the preferred order (this might no longer be necessary, but liboscar  
at one point, IIRC, listed JPEG before GIF in its prpl struct), and  
the image wells used for drag & drop of images are deliberately  
designed to maintain animation. Apple's own image-getting classes drop  
all animation from files, generally...

And yes, people definitely get really cranky when buddy icons don't  
animate.  It's a common enough question that it's in the documentation:

On Aug 28, 2007, at 10:17 AM, Andreas Monitzer wrote:

>> I don't understand this -- we already do some image conversions, and
>> we don't require any additional libraries to do so.  GdkPixbuf is
>> perfectly capable of converting among the formats it understands
>> (gdk_pixbuf_save_to_buffer).
> Ah ok, so glib already provides this, I didn't know that.

GdkPixbuf is part of GTK+, isn't it?  Adium does image conversion  
before passing image data to libpurple utilizing NSImage, a Cocoa  
class; Pidgin does so using GdkPixbuf before passing data to libpurple.

On Aug 28, 2007, at 8:07 AM, Etan Reisner wrote:

> I've never used a gateway in my life nor do I know anything about the
> protocol for them so I'm not really qualified to discuss that aspect  
> of
> things, but I think assuming anything about any roster item is  
> broken. If
> there is no other way reliably determine when something is a gateway  
> then
> I think the protocol for them is broken and I would rather not  
> support it.
> (I realize that doesn't help the Adium folks who seem to want to  
> support
> anything if they can at all do so, but assumptions that 'break'  
> things are
> bad and I don't think they belong in libpurple.)

Assumptions that break things are unequivocally bad.  I disagree with  
the claim that Adium wants  "support anything if they can at all do  
so," and offer that the request for transport support (an old, old  
request, which incidentally I haven't heard in a while, but that may  
just be because the people who want it got sore throats from yelling)  
isn't unreasonable -- transports are supported by XMPP and can help  
people who are able to connect to a Jabber server but not to other  
messaging services.  So long as it's done properly and at least one UI  
is making use of it (as unused code is oft broken code), making  
libpurple a more complete XMPP implementation seems like a win to me.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Devel mailing list