registry team mailing list archive
-
registry team
-
Mailing list archive
-
Message #15186
[Bug 404022] Re: Empathy shows my ICQ number instead of my Nickname
Launchpad has imported 14 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=13124.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2007-11-07T06:05:38+00:00 Will Thompson wrote:
This is mainly because libpurple provides no protocol-independent
mechanism to set your server alias/friendly name/whatever.
Someone claimed they were adding the necessary API, but it has not
materialized.
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/0
------------------------------------------------------------------------
On 2008-05-08T12:27:04+00:00 Shadowarts wrote:
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?
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/1
------------------------------------------------------------------------
On 2008-05-08T13:03:27+00:00 Will Thompson wrote:
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.
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/2
------------------------------------------------------------------------
On 2009-08-21T01:40:22+00:00 Nicolò Chieffo wrote:
I forwarded it here: http://developer.pidgin.im/ticket/10005
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/5
------------------------------------------------------------------------
On 2009-11-28T04:22:00+00:00 jango wrote:
Found Bug on Gnome Bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=599304
and Launchpad:
https://bugs.launchpad.net/telepathy-haze/+bug/404022
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/9
------------------------------------------------------------------------
On 2010-02-22T05:56:18+00:00 Will Thompson wrote:
*** Bug 26697 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/10
------------------------------------------------------------------------
On 2010-07-15T09:11:17+00:00 Simon McVittie wrote:
(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.
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/17
------------------------------------------------------------------------
On 2010-07-18T06:41:01+00:00 Felipe Contreras wrote:
(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.
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/18
------------------------------------------------------------------------
On 2010-07-18T06:42:52+00:00 Felipe Contreras wrote:
Created an attachment (id=37172)
Proposed patch
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/19
------------------------------------------------------------------------
On 2010-07-18T06:46:22+00:00 Felipe Contreras wrote:
(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.
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/20
------------------------------------------------------------------------
On 2010-07-19T03:20:34+00:00 Simon McVittie wrote:
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?
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/22
------------------------------------------------------------------------
On 2010-07-19T14:34:13+00:00 Felipe Contreras wrote:
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.
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/23
------------------------------------------------------------------------
On 2010-08-06T07:30:46+00:00 Simon McVittie wrote:
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@xxxxxxxxxxx 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@xxxxxxxxxxx' changed alias from "SMcV" to "SMcV"
purple/msn-Message: Update contact information for XXXXXX@xxxxxxxxxxx with new display name: omg
purple/blist-Message: Updating buddy status for XXXXXX@xxxxxxxxxxx (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...
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/24
------------------------------------------------------------------------
On 2010-08-06T08:08:56+00:00 Felipe Contreras wrote:
(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@xxxxxxxxxxx 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@xxxxxxxxxxx' changed alias from "SMcV" to "SMcV"
> purple/msn-Message: Update contact information for XXXXXX@xxxxxxxxxxx with new
> display name: omg
> purple/blist-Message: Updating buddy status for XXXXXX@xxxxxxxxxxx (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)
Reply at: https://bugs.launchpad.net/empathy/+bug/404022/comments/25
** Changed in: telepathy-haze
Status: Confirmed => In Progress
** Changed in: telepathy-haze
Importance: Unknown => Medium
** Bug watch added: Pidgin Trac #10005
http://developer.pidgin.im/ticket/10005
--
Empathy shows my ICQ number instead of my Nickname
https://bugs.launchpad.net/bugs/404022
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for Telepathy Haze.
