Use case for per-protocol icons

[Etan Reisner]

On Mon, Aug 06, 2007 at 08:55:25PM -0400, Andrew Roeder wrote:
<snip>
> On 8/06/07, Ethan Blanton elb at pidgin.im wrote:
> >None of that is really what happens.  It just so happens that a small
> >number of users, including yourself, appear to be incapable of logical
> >argument or decision-making.  We have presented, for *every single*
> >use case that has come up (unless I'm forgetting something), a
> >superior way to solve the problem to using protocol icons.  A few of
> >them do not exist in the current Pidgin UI, or did not at the time of
> >discussion and have since been implemented.
>
> Except for the one I just stated in my previous mailing list post, which I
> have not seen arise except from my own arguments, which you yourself decided
> not to respond to, but instead felt it necessary to tell me that I'm
> illogical and bad at decisions.
>
> Excerpt:
> As I said previously on this subject, currently you must mouseover to find
> the protocol of a buddy in the buddy list, even if I have their "aliases"
> expanded or not together, when you want to rightclick on a buddy to use a
> feature, you may find that many options are not present, or that you can
> invite some buddies to a chat while others you can not(because they are on a
> different protocol.)  Having the icons clearly displayed constantly in the
> buddy list on a per-buddy-account basis alleviates that, allowing you to
> immediately know who is on what protocol, so you immediately know which
> buddies you may invite to chat on a protocol, and what features you may use
> for that buddy(s).
>
> If you have an alternative idea to this problem, please tell me what it is.

This is the 'different protocols have different features' argument, which
has come up before and has been answered numerous times. It almost
universally was brought up in regards to file-transfer and the response is
really most appropriate to something like file transfer that just needs to
work. Also, you will not find that features are not present if any of the
buddies are online because the 'extra' buddies will show up at the bottom
of the right-click menu, giving you instantaneous actions to each
sub-buddy at the price of a single menu level. So, no, you don't need the
protocol icon to access the protocol specific features since anything
protocol specific will live in the right-click menu anyway.

Also, to repeat the argument from file transfers: "But I need to know the
protocol because pidgin only supports file transfers on some protocols."
to which the response is "No, you don't need to know if pidgin can
intelligently pick the first buddy to whom you can successfully tranfer
files, which is not yet a feature pidgin has but is a feature we think it
should have.

> >"I want it because I want it" is not a good reason for a feature.  The
> >beautiful thing about Open Source, however, is that you don't *have*
> >to have buy-in from us, just because you want something that we don't.
> >Go to it.
>
> It is my understanding that the Plugin system as is currently can't
> accommodate the change, forking a separate version of Pidgin for one UI
> change would probably be more unaccepted than the change itself.

The plugin system can override the current status icon with protocol
specific icons which is the interface gaim used to present (modulo status
emblems which are virtually never included in the requests for this
feature). They can't (easily) add a column to the buddy list for the
protocol icon though.

> ~
> I'm not attacking the Pidgin development cycle by my previous statement, but
> the now hostile responses given whenever this subject is risen.  If you must
> repeat your reasons, simply copy and paste them, please do not just say
> "This has been discussed and we have better ways."

No, copying and pasting is not a suitable response to people who
continuously fail to read, continually abuse us for having stated our
opinions, and repeatedly fail to even consider that we are thinking human
beings who might have reasons for having done things.

	-Etan