Some Empathy bugs [1] [2] seem to suggest that we have to pull alias (and others contact info) from the ICQ server. Pidgin does that by exposing "Retrieve contact details" in the UI which is something we don't want to do in Empathy. So I guess haze should pull these info automatically so it always has all the info about the contacts. [1] https://bugzilla.gnome.org/show_bug.cgi?id=590595 [2] https://bugzilla.gnome.org/show_bug.cgi?id=602229
Also found on Launchpad: https://bugs.launchpad.net/empathy/+bug/474527 Empathy shows icq numbers instead of names (aliases): "I' ve just updated my Jaunty to Karmic. I added my icq account to empathy. In my contact list there are shown almost only icq numbers instead of names (aliases). Moreover, when I try to get Contact Information i also see only number, no alias. It's quite annoying because I don't know who is who..."
I just created an ICQ account and tested this with ven, a user from #telepathy. Interesting results. From ven's side: • haze logged from get_alias() that my user name was my UIN, but on the Empathy roster it quickly/immediately changed to my alias. • contacts for which ven has set a custom alias show up properly; other contacts do not. From my side: • ven shows up on my Empathy contact list as a UIN. • Haze's debug output shows it suppressing a system message being written to the conversation window showing "<uin> is now known as ven". There are two places in libpurple which produce that message. Following the code around, the one we're hitting ought to be emitting blist-node-aliased, but it doesn't seem to be. More investigation needed.
Woo hoo! Here's a branch that should fix this (and which tidies up connection-aliasing.c a bunch too).
To clarify: 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. So this branch makes setting a contact's alias to their ID a no-op. I'm wondering about making the alias lookup code explicitly ignore the local alias if it's the user's UIN, and try the remote nickname instead. Thoughts?
(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.
This is also a problem when you get requests from people you don't know. It happens quite often that there are spammers around and you have to look up the id on people.icq.com in order to see whats their name and alias. There is a new on empathy for this: https://bugzilla.gnome.org/show_bug.cgi?id=625402
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-haze/issues/27.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.