Bug 13124

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?

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.

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

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

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

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

(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.

(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.

Created attachment 37172 [details] [review]
Proposed patch

(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.

Review of attachment 37172 [details] [review]:

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?

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] [review]:
> 
> 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.

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 XXXXXX@hotmail.com 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 'XXXXXX@hotmail.com' changed alias from "SMcV" to "SMcV"
purple/msn-Message: Update contact information for XXXXXX@hotmail.com with new display name: omg
purple/blist-Message: Updating buddy status for XXXXXX@hotmail.com (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...

(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 XXXXXX@hotmail.com 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
> 'XXXXXX@hotmail.com' changed alias from "SMcV" to "SMcV"
> purple/msn-Message: Update contact information for XXXXXX@hotmail.com with new
> display name: omg
> purple/blist-Message: Updating buddy status for XXXXXX@hotmail.com (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)

yeah, this all looks kosher. did anyone file a bug against the stock prpl?

Fixed in git for 0.4.1 and 0.5.0, which will both depend on libpurple 2.7 as a result (Maemo 5 Extras have caught up with that version, so it seems reasonable to have a hard dependency even in the stable branch).

(In reply to comment #14)
> did anyone file a bug against the stock prpl?

I haven't yet; perhaps someone with a login there (Felipe?) could do so?

I am so sorry I was applying the patch on Ubuntu 11.04 (I have this issue on telepathy)...

[quote]carlos@ubuntu:~$ patch -p0 < 0001-aliasing-use-new-public_set_alias.patch
bash: 0001-aliasing-use-new-public_set_alias.patch: Ficheiro ou directoria inexistente[/quote]

It says here that the file or the directory is inexistent...

(Changing the resolution back to FIXED… Carlos, did you mean to change it to WONTFIX?)

And, wow, I haven't made a Haze release for … 11 months. Sorry about that. I'll cut a release now.

You're trying to apply a source code patch in your home directory, which is never going to work. The patch has been merged to Git master; if you want to try the latest development version of Haze, you'll want to clone and build <http://cgit.freedesktop.org/telepathy/telepathy-haze> — but better just wait for Haze 0.5.0.

(In reply to comment #17)
> (Changing the resolution back to FIXED… Carlos, did you mean to change it to
> WONTFIX?)
> 
> And, wow, I haven't made a Haze release for … 11 months. Sorry about that. I'll
> cut a release now.
> 
> You're trying to apply a source code patch in your home directory, which is
> never going to work. The patch has been merged to Git master; if you want to
> try the latest development version of Haze, you'll want to clone and build
> <http://cgit.freedesktop.org/telepathy/telepathy-haze> — but better just wait
> for Haze 0.5.0.

Sorry I'm quite new to this, I meant that it doesn't fix to me... I have Ubuntu for 2 days :( But I have 9 years of windows so I know my ways ;) .

(In reply to comment #18)
> (In reply to comment #17)
> > (Changing the resolution back to FIXED… Carlos, did you mean to change it to
> > WONTFIX?)
> > 
> > And, wow, I haven't made a Haze release for … 11 months. Sorry about that. I'll
> > cut a release now.
> > 
> > You're trying to apply a source code patch in your home directory, which is
> > never going to work. The patch has been merged to Git master; if you want to
> > try the latest development version of Haze, you'll want to clone and build
> > <http://cgit.freedesktop.org/telepathy/telepathy-haze> — but better just wait
> > for Haze 0.5.0.
> 
> Sorry I'm quite new to this, I meant that it doesn't fix to me...

WONTFIX is used by developers to say “we will not fix this bug” and/or “we don't think this is a bug”. In this case, the bug was fixed, just not released.

> I have Ubuntu
> for 2 days :( But I have 9 years of windows so I know my ways ;) .

I released version 0.5.0 of telepathy-haze just now. It'll show up in the Telepathy PPA soon, I hope.

Sorry I am just a newbie ^^

still occures in the Ubuntu 12.04 beta with telepathy-haze 0.5.0-1

I had it confirmed by a friend so it occurs in two independent systems with that version of the package

Which is me. I am using Arch Linux with:

empathy 3.2.2
telepathy-haze 0.5.0
libpurple 2.10.2

Though the bug is marked as fixed, I still cannot change aliases of haze accounts.

(In reply to comment #6)
> Note that in current libpurple, only the MSN prpl can take advantage of this.

Are you trying to set the alias of MSN or non-MSN accounts?

If you're trying to set the alias of non-MSN accounts and it doesn't work, that probably means the prpl (libpurple protocol plugin) for that protocol doesn't support setting your own alias yet. As of libpurple 2.7.0, the MSN prpl was the only one to support this.

If other prpls are enhanced to work the same way as the MSN one (if that hasn't already been done, it would be a libpurple feature request), then they should work in Haze.

Indeed, the problem is with non-MSN accounts, ICQ and Yahoo specifically.

(In reply to comment #25)
> Indeed, the problem is with non-MSN accounts, ICQ and Yahoo specifically.

Then that's not a Haze bug; please ask the developers of Pidgin (libpurple) to support the virtual methods used by purple_account_set_public_alias() in the ICQ and Yahoo prpls.