No subject

advanced user of an IM application, and that those few who do are almost
all either IM developers, or potential IM developers/plugin authors.  

As I was thinking about these things, and as other Pidgin developers
were thinking about them with me, I came to read (I am not sure if I
read it first, or if another developer pointed me at it) an article
talking about the reality that many preferences are not really
necessarily.  They exist because someone changed the behavior of a
program in a way that user B did not like.  Not wanting to say "this
change is wrong for all users," or perhaps not being able to defend such
a position, user B asked that it be made optional.  Looking at our own
preferences at the time, it was IMMEDIATELY obvious that some of our
preferences existed for PRECISELY this reason.  

The article continued, saying that in fact, in many cases, the right
answer was that *neither* behavior was correct, but that there was an
underlying issue here that if addressed, would negate the need for a
preference.  This seemd persuasive.

I think that most of the arguments for protocol icons in the buddy list
fall into this category.  Things do not work quite right, and having the
protocol icon allows you to work around the flaw.  It doesn't solve the
flaw, but it lets you work around it.  Not having the protocol icon does
not stop you from working around these flaws, but it does require
_different_ work arounds.  

I would argue, that as far as work arounds go, the ones we have been
suggesting are superior to protocol icons in the buddy list.  That is,
however, largely a side point.  Most of these things, particularly the
handling of file transfer and offline messages, represent bugs that can
and should be fixed.  Some of them, like offline messages, represent
bugs that can relatively easily be fixed now that our attention has been
drawn to them.  

As the bugs cease to exist, your need for _any_ work around, either
those we have proposed, or the protocol icons, will cease.

luke