evan.s at dreskin.net
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
>>>> 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'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
> 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
> 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
> 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
> 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...
More information about the Devel