[Pidgin] #562: case for old icons: Advantagous heuristics of differentiated protocol icons

[Pidgin]

#562: case for old icons: Advantagous heuristics of differentiated protocol icons
---------------------------+------------------------------------------------
  Reporter:  Ash           |       Owner:                
      Type:  defect        |      Status:  closed        
  Priority:  minor         |   Milestone:                
 Component:  pidgin (gtk)  |     Version:  2.0           
Resolution:  duplicate     |    Keywords:  icons protocol
   Pending:  0             |  
---------------------------+------------------------------------------------
Comment (by elb):

 Replying to [comment:8 merwin]:
 > What about this reasoning:
 > I want to prune my contact list down on a certain protocol. I recently
 re-added an old Yahoo IM account that I hadn't used in a year or two.
 There are a lot of people on there that I want to remove, but I don't know
 which contacts are Yahoo and which are other protocols. I suppose I could
 mouse over each contact to find out the protocol, but that is very
 cumbersome and makes the process take much longer.

 I suggest signing off your other accounts for the time necessary to prune
 that list.

 > I just don't understand the argument of putting it back being complex,
 as it would just be an option in the configuration and another column in
 the contact list with the protocol of whichever contact is on-top.

 It is clear from this, and your next comment, that you don't understand
 this because you are not a programmer.  That is fine, but it does make
 assertions like "it would just be ..." somewhat shady.  Any time there is
 a portion of code which is only exercised ''sometimes'', there is
 disproportionate cost for maintaining that code.  You are sort of correct,
 in that the cost is not ''that'' great, but it is greater than the value
 of the option (which is very nearly nil).

 > And to the people who say to write a plugin yourself to do it. I'm sure
 that many of us would like to have the spare time to write such a plugin,
 however most of us don't. Why is it so difficult for one of the existing
 developers to implement it as a plugin that is included with Pidgin?

 But you assume that the regular developers do have the spare time to write
 such a plugin, apparently without even any idea of how much time that
 would be?  Interesting logic...

-- 
Ticket URL: <http://developer.pidgin.im/ticket/562#comment:9>
Pidgin <http://pidgin.im>
Pidgin