[Pidgin] #17295: Presence/alias for non-buddies not shown
trac at pidgin.im
Fri Mar 16 06:38:52 EDT 2018
#17295: Presence/alias for non-buddies not shown
Reporter: dwmw2 | Owner: EionRobb
Type: defect | Status: new
Milestone: | Component: unclassified
Version: 2.13.0 | Resolution:
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
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
• 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.
> 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>
More information about the Tracker