Empathy not showing notifications of a second user

Bug #552543 reported by Conscious User on 2010-03-31
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Empathy
New
Medium
empathy (Ubuntu)
Low
Unassigned
notify-osd (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: empathy

Steps to reproduce:

1 - Open empathy as a certain user A and hide the chat window.
2 - Make a first user B to send user A a couple of messages.
3 - Immediately after, make a second user C send user A a message.

User A should receive notifications for the messages of user B, but no notification for the messages of user C. But those notifications will afterwards appear whenever Empathy is interacted with somehow (opening a chat window, for example).

According to investigation made by Nicolò Chieffo in Bug #476662, this is intended behavior in vanilla Empathy: the user is supposed to receive the remaining notifications only after clicking on the status icon. Empathy developers intend to keep it this way until there's a way to selectively open chat windows. Ubuntu Empathy, however, *does* have such a way already: the Messaging Menu.

The code that "eats" notifications from the second user onwards should be modified to do so *only* if the regular status icon is being used (i.e. the messaging menu is not being used). Apparently, the logic is in empathy-status-icon.c.

Conscious User (conscioususer) wrote :

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

Changed in empathy (Ubuntu):
status: New → Confirmed
Nicolò Chieffo (yelo3) wrote :

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?

Conscious User (conscioususer) wrote :

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.

Conscious User (conscioususer) wrote :

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)

Brian Curtis (bcurtiswx) wrote :

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?

Brian Curtis (bcurtiswx) wrote :

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?

Conscious User (conscioususer) wrote :

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.

Conscious User (conscioususer) wrote :

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.

Nicolò Chieffo (yelo3) wrote :

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?

Conscious User (conscioususer) wrote :

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.

Conscious User (conscioususer) wrote :

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.

Conscious User (conscioususer) wrote :

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?

Omer Akram (om26er) on 2011-01-12
Changed in empathy (Ubuntu):
status: Confirmed → Incomplete
Omer Akram (om26er) wrote :

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)

Changed in empathy (Ubuntu):
importance: Undecided → Low
status: Incomplete → Triaged
Changed in empathy:
importance: Unknown → Medium
status: Unknown → New
Sebastien Bacher (seb128) wrote :

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

Changed in notify-osd (Ubuntu):
importance: Undecided → Low
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.