Comment 9 for bug 1175537

Thanks for testing. That buddy id was exactly what I was hoping to see, so at least that part seems to be fixed.

Problem 1, as Sebastien mentioned, was unfortunately always there. I'm not sure how to fix it. On my system at least, sometimes I will get the first notification, sometimes not. I think it could be related to the sign-on flood control code.

Problems 3 and 4 are actually by design. I think the Clear button's name is a bit misleading. It doesn't actually remove any of the menu items. It only clears the attention (the envelope changing color). Several separate menu items could all have attention set, and you would need to clear them all separately, so the button is just there to make it easy to remove them all at once. A menu item only disappears when you click on it, or when you close the conversation that is associated with it.

Problem 2 is interesting. For IM messages, the unseen-count of a conversation is used to determine if attention should be set. There could be two reasons why this isn't working. It could be that pidgin thinks you have the conversation focused for some reason. You said that you had it open on a separate workspace, so maybe it can't tell the difference. You could test this by minimizing the conversation and then sending the messages.

The other option is that for some reason purple_conversation_get_name() is not matching purple_buddy_get_name(). You said that it was working before, so that would point to purple_conversation_get_name() being the same as sender (so the buddy name with all the random bits at the end). If this is the case (we'd need to add some debugging messages to test), that would point to a bug in pidgin for that protocol, since the API reference says it returns "The conversation's name. If the conversation is an IM with a PurpleBuddy, then it's the name of the PurpleBuddy."

Actually looking at the jabber protocol code, in message.c they use purple_conversation_set_name() and describe it as:

* We received a message from a specific resource, so
* we probably want a reply to go to this specific
* resource (i.e. bind/lock the conversation to this
* resource).
*
* This works because purple_conv_im_send gets the name
* from purple_conversation_get_name()

So it seems it might be a quirk of the jabber code. Unless I could somehow get a buddy back out of a conversation, then I'm not sure how to fix this.

Sebastien, it's hard to say. It's probably better that the envelope doesn't change color when it should, versus flooding the Messaging Menu with duplicate entries. I'm not sure how fixable this is without adding some custom parsing for conversations with the jabber protocol.