Empathy will not save Alias names for Yahoo and ICQ account.

[robert4380]

Binary package hint: empathy

In Empathy, when going into Edit >> Personal Information, the program refuses to save any alias that I set for my Yahoo account. The alias listed is always the same as my account ID. For example, if my Yahoo ID is robert1234, and I want to set my alias as "Bob," Empathy will not let me do this. Overall, I think that Pidgin is a much better IM client. I'm also not a fan at all of the "set status" options in the main Ubuntu task bar that interface with Empathy or other IM clients.

ProblemType: Bug
Architecture: i386
Date: Tue Nov 3 21:20:01 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/empathy
InstallationMedia: Ubuntu-Netbook-Remix 9.10 "Karmic Koala" - Release i386 (20091028.4)
Package: empathy 2.28.1-1ubuntu1
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: empathy
Tags: ubuntu-unr
Uname: Linux 2.6.31-14-generic i686

[Shadowarts (shadowarts)]

I was poking around on the Trac for libpurple and found this:

http://developer.pidgin.im/doxygen/2.2.0/html/account_8h.html#62c7f2f940b5da2091564321ad2fbde8

Wouldn't that mechanism be enough to set your own alias?

[Will Thompson (wjt)]

No. purple_account_set_alias sets the local alias for the account, which is what Pidgin displays as your name in your own conversation windows. It does not set the public alias that other people can see.

[Nicolò Chieffo (yelo3)]

I forwarded it here: http://developer.pidgin.im/ticket/10005

[robert4380 (robert4380)]

Binary package hint: empathy

In Empathy, when going into Edit >> Personal Information, the program refuses to save any alias that I set for my Yahoo account. The alias listed is always the same as my account ID. For example, if my Yahoo ID is robert1234, and I want to set my alias as "Bob," Empathy will not let me do this. Overall, I think that Pidgin is a much better IM client. I'm also not a fan at all of the "set status" options in the main Ubuntu task bar that interface with Empathy or other IM clients.

ProblemType: Bug
Architecture: i386
Date: Tue Nov 3 21:20:01 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/empathy
InstallationMedia: Ubuntu-Netbook-Remix 9.10 "Karmic Koala" - Release i386 (20091028.4)
Package: empathy 2.28.1-1ubuntu1
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: empathy
Tags: ubuntu-unr
Uname: Linux 2.6.31-14-generic i686

[Sebastien Bacher (seb128)]

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

[Stefan Hammer (j-4-deactivatedaccount)]

Found Bug on Gnome Bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=599304

and Launchpad:
https://bugs.launchpad.net/telepathy-haze/+bug/404022

[lingenfr (lingenfr)]

Then please fix apport so that we can follow the instructions on the wiki. In this case, Using Empathy>Help>Report a bug does not take you to the right place to report a bug. I went to the link you provided, searched packages, navigated to Empathy and clicked the link for Report a bug and it took me back to the same place. Not helpful. I will keep looking for the correct place to report an Empathy bug, but obviously Empathy is not yet ready to be the default IM client.

[varanasi (mark-hugheshome)]

Here's the link for reporting an empathy bug. This one is sort of reported but not as well as you did it:

https://bugzilla.gnome.org/enter_bug.cgi?product=empathy

The closest report is filed as related to windows:
https://bugzilla.gnome.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=empathy&content=alias

[Omer Akram (om26er)]

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at: https://bugzilla.gnome.org/show_bug.cgi?id=607795

[Will Thompson (wjt)]

*** Bug 26697 has been marked as a duplicate of this bug. ***

[Omer Akram (om26er)]

this is not a bug in empathy its a feature in haze that is not implemented. Thanks for the bug report

[Sennaista (sennaista)]

The same thing on 64 bit Lucid.

[Simon McVittie (smcv)]

(In reply to comment #0)
> This is mainly because libpurple provides no protocol-independent mechanism to
> set your server alias/friendly name/whatever.

Since 2.7.0, it does; see attached (rather simplistic) patch.

Note that in current libpurple, only the MSN prpl can take advantage of this.

[Felipe Contreras (felipec)]

(In reply to comment #6)
> Since 2.7.0, it does; see attached (rather simplistic) patch.

Which patch?

For the record, I have been pushing for this feature since a long time, and my latest proposal didn't receive any comments from Pidgin devs:
http://pidgin.im/pipermail/devel/2010-January/009177.html

My suggested patch for haze was in #26119.

It seems they added the API on 2.7.0 without even mentioning where the idea came from, nor discussing it with any potential users, and they aren't exercising it in any of their UI's. They decided it was a good idea to have callbacks without user_data pointers (silly IMO).

Anyway, fortunately it seems we don't need those pointers for now. I'm attaching a patch.

[Felipe Contreras (felipec)]

Created an attachment (id=37172)
Proposed patch

[Felipe Contreras (felipec)]

(In reply to comment #7)
> (In reply to comment #6)
> > Since 2.7.0, it does; see attached (rather simplistic) patch.
>
> Which patch?

Ah, in the URL. Well, AFAICR I tried something like that on Maemo5 and it didn't work correctly: the UI wasn't aware of the change.

[Simon McVittie (smcv)]

Review of attachment 37172:

You're right that producing change notification signals is desirable, so your patch is better than mine; thanks!

I think your patch is likely to end up with the change notification getting out of sync with the state recovery, due to Bug #25869? It's better than nothing, though.

(What I mean by that is: calling RequestAliases or whatever, just after the change signal, won't give the same answer as the signal)

I'd be inclined to not do the error reporting yet (i.e. behave like we both did here); I'll open a bug for the lack of error reporting.

::: src/connection-aliasing.c
@@ +179,2 @@
 static void
+set_alias_succeess_cb (PurpleAccount *account,

It's spelled "success" :-)

@@ +189,3 @@
+ g_value_init (&entry, HAZE_TP_ALIAS_PAIR_TYPE);
+ g_value_take_boxed (&entry,
+ dbus_g_type_specialized_construct (HAZE_TP_ALIAS_PAIR_TYPE));

It'd be better to include <telepathy-glib/gtypes.h> and use TP_STRUCT_TYPE_ALIAS_PAIR (we should kill off all the HAZE_TP_*_TYPE at some point, now that telepathy-glib generates them all).

With the change I suggest below, this wouldn't be necessary anyway.

@@ +197,3 @@
+
+ aliases = g_ptr_array_sized_new (1);
+ g_ptr_array_add (aliases, g_value_get_boxed (&entry));

We know that TP_STRUCT_TYPE_ALIAS_PAIR is a GValueArray<uint,string>, so since telepathy-glib 0.9.2 (sadly not available on Maemo 5), you could delete @entry entirely, and use:

aliases = g_ptr_array_sized_new (1);
g_ptr_array_add (aliases, tp_value_array_build (2,
    G_TYPE_UINT, base_conn->self_handle,
    G_TYPE_STRING, new_alias,
    G_TYPE_INVALID));

To make backporting to Maemo 5 easier, perhaps you could implement my other suggestions from above (producing a patch suitable for backporting to Maemo), then do this simplification as a second patch?

[Felipe Contreras (felipec)]

Hmm, all bugzillas I've seen add me to the Cc list by default... I just noticed I didn't receive a notification of this comment =/

(In reply to comment #10)
> Review of attachment 37172 [details]:
>
> You're right that producing change notification signals is desirable, so your
> patch is better than mine; thanks!
>
> I think your patch is likely to end up with the change notification getting out
> of sync with the state recovery, due to Bug #25869? It's better than nothing,
> though.

Well, it works fine on Maemo5 and Empathy: I see my nickname on the chat window.

> (What I mean by that is: calling RequestAliases or whatever, just after the
> change signal, won't give the same answer as the signal)
>
> I'd be inclined to not do the error reporting yet (i.e. behave like we both did
> here); I'll open a bug for the lack of error reporting.
>
> ::: src/connection-aliasing.c
> @@ +179,2 @@
> static void
> +set_alias_succeess_cb (PurpleAccount *account,
>
> It's spelled "success" :-)

Agh, typo.

> @@ +189,3 @@
> + g_value_init (&entry, HAZE_TP_ALIAS_PAIR_TYPE);
> + g_value_take_boxed (&entry,
> + dbus_g_type_specialized_construct (HAZE_TP_ALIAS_PAIR_TYPE));
>
> It'd be better to include <telepathy-glib/gtypes.h> and use
> TP_STRUCT_TYPE_ALIAS_PAIR (we should kill off all the HAZE_TP_*_TYPE at some
> point, now that telepathy-glib generates them all).

Ok, I just copy-pasted the code from somewhere else.

> With the change I suggest below, this wouldn't be necessary anyway.
>
> @@ +197,3 @@
> +
> + aliases = g_ptr_array_sized_new (1);
> + g_ptr_array_add (aliases, g_value_get_boxed (&entry));
>
> We know that TP_STRUCT_TYPE_ALIAS_PAIR is a GValueArray<uint,string>, so since
> telepathy-glib 0.9.2 (sadly not available on Maemo 5), you could delete @entry
> entirely, and use:
>
> aliases = g_ptr_array_sized_new (1);
> g_ptr_array_add (aliases, tp_value_array_build (2,
> G_TYPE_UINT, base_conn->self_handle,
> G_TYPE_STRING, new_alias,
> G_TYPE_INVALID));
>
> To make backporting to Maemo 5 easier, perhaps you could implement my other
> suggestions from above (producing a patch suitable for backporting to Maemo),
> then do this simplification as a second patch?

Ok, but I think the first patch should be just like the current patch... The second one might be of wider scope touching other parts of the code that have the same issues.

[Simon McVittie (smcv)]

I've done a branch based on Felipe's patch; I think it's ready for review, but it doesn't work ideally with the MSN prpl. When changing my alias from "wtf" to "omg", I get:

(haze:20880): haze-DEBUG: set_aliases_foreach: setting alias for myself to "omg"
purple/msn-INFO: C: NS 000: PRP 17 MFN omg
purple/msn-INFO: S: NS 000: PRP 17 MFN omg
purple/msn-Message: Update contact information for Me with new display name: omg
(haze:20880): haze-DEBUG: set_alias_success_cb: purple_account_set_public_alias succeeded, new alias omg
purple/msn-INFO: S: NS 000: NLN NLN <email address hidden> 1 omg 1074004004 0

but then the blist-node-aliased signal fires, and gives me a different alias, that I haven't used since several attempts ago:

(haze:20880): haze-DEBUG: blist_node_aliased_cb: Contact #1 '<email address hidden>' changed alias from "SMcV" to "SMcV"
purple/msn-Message: Update contact information for <email address hidden> with new display name: omg
purple/blist-Message: Updating buddy status for <email address hidden> (MSN)

This appears to be because I *also* have an AB.Nickname for myself (possibly from Butterfly?), which is "SMcV", overrides the public alias, and can't be changed via Haze.

Still, if it works in some situations (lack of an AB.Nickname), it's a minor improvement...

[Felipe Contreras (felipec)]

(In reply to comment #12)
> I've done a branch based on Felipe's patch; I think it's ready for review, but
> it doesn't work ideally with the MSN prpl. When changing my alias from "wtf" to
> "omg", I get:
>
> (haze:20880): haze-DEBUG: set_aliases_foreach: setting alias for myself to
> "omg"
> purple/msn-INFO: C: NS 000: PRP 17 MFN omg
> purple/msn-INFO: S: NS 000: PRP 17 MFN omg
> purple/msn-Message: Update contact information for Me with new display name:
> omg
> (haze:20880): haze-DEBUG: set_alias_success_cb: purple_account_set_public_alias
> succeeded, new alias omg
> purple/msn-INFO: S: NS 000: NLN NLN <email address hidden> 1 omg 1074004004 0
>
> but then the blist-node-aliased signal fires, and gives me a different alias,
> that I haven't used since several attempts ago:
>
> (haze:20880): haze-DEBUG: blist_node_aliased_cb: Contact #1
> '<email address hidden>' changed alias from "SMcV" to "SMcV"
> purple/msn-Message: Update contact information for <email address hidden> with new
> display name: omg
> purple/blist-Message: Updating buddy status for <email address hidden> (MSN)
>
> This appears to be because I *also* have an AB.Nickname for myself (possibly
> from Butterfly?), which is "SMcV", overrides the public alias, and can't be
> changed via Haze.
>
> Still, if it works in some situations (lack of an AB.Nickname), it's a minor
> improvement...

Yes, this would only happen if:
a) the user has himself on the list
b) has a private alias for himself
c) is using the stock msn protocol

(Works fine on msn-pecan)

[chaghaboo (marko.niketic)]

Same thing here with Yahoo account, while MSN and Gmail are working fine considering this.