** Changed in: empathy
Status: New => Expired
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to empathy in Ubuntu.
https://bugs.launchpad.net/bugs/552543
Title:
Empathy not showing notifications of a second user
To manage
the issue seems an empathy one, not a notify-osd bug
** Changed in: notify-osd (Ubuntu)
Importance: Undecided = Low
** Changed in: notify-osd (Ubuntu)
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to
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)
Status: Confirmed = Incomplete
** Bug watch added: GNOME Bug Tracker
** Changed in: empathy
Status: Unknown = New
** Changed in: empathy
Importance: Unknown = Medium
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to empathy in ubuntu.
https://bugs.launchpad.net/bugs/552543
Title:
Empathy
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
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?
--
Empathy not showing notifications of a second user
https://bugs.launchpad.net/bugs/552543
You received
Based on all investigation from Bug #476662, I will already mark this
bug as confirmed.
** Changed in: empathy (Ubuntu)
Status: New = Confirmed
--
Empathy not showing notifications of a second user
https://bugs.launchpad.net/bugs/552543
You received this bug notification because you are
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
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.
--
Empathy not showing notifications of a
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
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?
--
Empathy not showing notifications of a second user
https://bugs.launchpad.net/bugs/552543
You received this bug
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.
** Also affects: notify-osd (Ubuntu)
Importance: Undecided
Status: New
--
Empathy not
This is not a problem of notify-osd, please close.
Can you propose a solution, when should the notifications be inhibited
and when not?
--
Empathy not showing notifications of a second user
https://bugs.launchpad.net/bugs/552543
You received this bug notification because you are a member of
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
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*
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
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
17 matches
Mail list logo
