Empathy not showing notifications of a second user

Based on all investigation from Bug #476662, I will already mark this bug as confirmed.

Ok, to tell the truth there's a little thing missing: if the notifications have an action (i.e. when using notification-daemon) when you click on the button, the first chat received will be opened, so also in this case (when it contains an action) the notifications should be inhibited until the first conversation is opened.
This could bring some problems, because I don't know what happens in the case of this scenario + the messaging menu: will the queued notifications be opened if the user clicks on the first conversation? and what happens if he opens the second coversation, then the first?

I'm testing right now.

"will the queued notifications be opened if the user clicks on the first conversation?"

That's precisely what happens.

"and what happens if he opens the second coversation, then the first?"

The queued notifications never appear.

Just to complete the test case set: if I click on neither conversation, but on the "Empathy" entry (thus opening the buddy list), nothing happens. The queued notifications do not appear but are not lost either: they will still be shown when you open the first conversation and will still be lost if you open the second one (and that includes opening them via the buddy list instead of the messaging menu)

So wouldn't a better bug title be "Notifications erased incorrectly upon opening conversations out of the order they were received in"

Making this a notify-OSD problem not empathy?

Also, it's not appropriate to confirm your own bug reports. I have added a notify-OSD task, and will wait for further comments before changing the title and possibly invalidating the empathy task.

This is not a problem of notify-osd, please close.

Can you propose a solution, when should the notifications be inhibited
and when not?

Brian, I am aware that it's not appropriate to confirm your own bug reports, but in this case it's not a new report, but a sub-issue already confirmed and previously discussed by more than one user in another report. Sorry if I caused any problems.

And I agree with Nicolò, I think the one incorrectly asking notifications to be canceled is Empathy, notify-osd is just correctly doing what is asked to do.

Nicolò, I think the current behavior can be kept exactly as it is if the status icon is present (i.e., the option "use message indicators" in the preferences is unchecked). When the status icon is not present (i.e. the messaging menu is being used), I think the expected behavior is to *never* inhibit notifications.

The 2 variables are
1) old status icon present
2) actions supported by the notification server

if (1 && 2) -> inhibit notifications
if (! 1 && ! 2) -> always show notifications
if (! 1 && 2) -> ??? (I think inhibit notifications)
if (1 && ! 2) -> ??? (I think always show notifications)

do you think this is correct?

If the opinion of a plain old non-developer average user matters to you, I agree with the first two cases and I'm not sure about the other two.

In the third case, if the first notification times out or is closed without being acted upon, that leaves no way of un-inhibiting the remaining notifications.

In the fourth case, there *is* a way of un-inhibiting the remaining notifications, which is clicking on the status icon. But it is completely non-intuitive that the user should do that in the first place.

I guess an official specification should be drafted.

The more I think about the subject the more I agree that the current Empathy behavior is wrong.

I took a time to see what Pidgin does in this case, and it seems to queue the conversation windows in the status icon: the status only goes out of attention mode when you clicked it a number of times corresponding to the number of users who you received notifications about. Each click opens the conversation window of one of those users, prioritizing most recent.

It's like the messaging menu, except that you don't choose the order you want to open the conversation windows. But this is not a big deal because (1) prioritizing most recent is reasonable and (2) the messaging menu induces you to do that anyway, by ordering the indicators in the same way.

In short, I think the full fix requires changing Empathy to do the following:

a) Always show notifications, regardless of situation. Never inhibit them.

b) Queue conversation windows in the status icon, like Pidgin does.

Patching (a) is probably trivial, while (b) is probably complex. It would be interesting to see what upstream has to say about this.

Nicolò, can you point me where the Empathy developers said they intend to keep the current behavior until there's a way to selectively open chat windows? Or was it private communication?

sent the bug to gnome. lets see what we get this time since with gnome-shell things should be different (I honestly have a very little clue about the situation of this bug report :p)

the issue seems an empathy one, not a notify-osd bug