Comment 13 for bug 476582

Revision history for this message
In , Simon McVittie (smcv) wrote :

(In reply to comment #4)
> The problem seems to have been that Empathy explicitly sets contacts' alias to
> their ID. So if the contact-specified nickname doesn't arrive fast enough —
> which it doesn't — the ICQ user's alias is forcibly set to their UIN, and then
> when their actual nickname arrives, we don't get it because we already have a
> user-set alias for the contact.

To be honest, this sounds like a problem with Empathy? It shouldn't really do that, and it'll hurt other CMs almost equally (it looks as though the only reason we have a bug report for ICQ and not for XMPP is that UINs are worse than JIDs).

IMO, the only time that Empathy should be setting a contact's alias is when the user explicitly sets it. Adding a new contact should fetch the existing nickname with RequestAliases to populate a text box, and let the user say "yes" to it; perhaps it should even not enable the [OK] button, or not pop up the dialog, or something, until RequestAliases (maybe with a shorter-than-default timeout) has returned?

In CMs where we automatically grab nicknames and store them in the roster for performance reasons (i.e. Gabble - thanks, XMPP), it's the CM's job to do that, and Empathy shouldn't duplicate it.

When we have a distinction between user-set (or at least user-approved) aliases (Bug #14540) it'll become more important to not trample on the user-set alias, but at least you'll be able to see the remotely-set nickname in the tooltip or something and work out who it is.