[Pidgin] #17295: Presence/alias for non-buddies not shown

[Pidgin]

#17295: Presence/alias for non-buddies not shown
--------------------+---------------------------
 Reporter:  dwmw2   |       Owner:  EionRobb
     Type:  defect  |      Status:  new
Milestone:          |   Component:  unclassified
  Version:  2.13.0  |  Resolution:
 Keywords:          |
--------------------+---------------------------

Comment (by dwmw2):

 Frankly, the printfs were the least of my worries at that point :)

 I think requiring the PRPL to add the buddy with the NO_SAVE flag makes
 sense — we can reasonably assume that it is already doing any refcounting
 it needs, and then we don't have to worry about that. The code in
 gtkconv.c which makes its own transient buddy (which it never uses
 anyway?) would then never really get invoked. This also means we don't
 have to add extra hooks/signals on purple_buddy_new() to allow the PRPL to
 set presence/alias for such buddies. (Currently a PRPL doesn't see a new
 buddy until purple_blist_add_buddy() is called.)

 However, there are still a few things I don't like about my current patch,
 so I'm thinking of simplifying it. I don't like the `group==NULL` special
 case, and the special `purple_find_buddy_transient()` function because we
 can't return nodes with `bnode->parent==NULL` to unsuspecting callers
 without causing crashes ''(I fixed three of those in my patch, for the
 callers I *had* changed to `purple_find_buddy_transient()`)''.

 So I'm thinking of doing it with an '''actual''' group instead, and just
 setting a flag in its node so that the UI knows not to display the group
 at all.

 This means that `purple_find_buddy()` would find those transient buddies,
 but that's OK.

 There are code paths in gtkconv.c which use purple_find_buddy() to decide
 whether to display an 'Add' or 'Remove' menu item for a given buddy — but
 that's already broken for NO_SAVE buddies anyway; I think. It'll display
 'Remove' for them when it should say 'Add'? By fixing that, we make
 everything work with a 'real' group, I think.

 So my plan is:

  • Add a `PURPLE_BLIST_NODE_FLAG_INVISIBLE`
  • Make `purple_find_buddy()` return `NO_SAVE` or `INVISIBLE` buddies only
 if no buddy ''without'' those flags exists.
  • Make `gtkconv.cc::gray_stuff_out()` and similar code check the
 `NO_SAVE` and `INVISIBLE` flags and
    treat invisible/nosave buddies as if there are none ''(i.e. display the
 'Add' menu option)''

 And in my PRPL (which for the sake of this discussion we'll pretend is
 SIPE) I'll:

  • Create a group with the `INVISIBLE` flag
  • Add all contacts (chat room users, IM peers) to that group, also with
 `INVISIBLE` and `NO_SAVE` flags.

 Finally...

 >  Names in group chats (I saw you mention this on the mailing list) can
 be overridden by setting the alias of the chat room user

 In `libpurple/conversation.c` that is always obtained by
 `purple_find_buddy() + purple_buddy_get_contact_alias()`, which is why I
 lumped it under the 'transient buddies' issue.

 I haven't experimented with calling `purple_conv_chat_get_users()`, then
 walking that list and silently updating the aliases to the correct value.
 That seems nasty, and I think I'd also have to hack in a call to the
 `ui_ops->chat_rename_user()` too; is there a better way?

--
Ticket URL: <https://developer.pidgin.im/ticket/17295#comment:2>
Pidgin <https://pidgin.im>
Pidgin