Notify-OSD should be suppressed when using the sound menu

Reported by Owais Lone on 2010-10-01
176
This bug affects 30 people
Affects Status Importance Assigned to Milestone
Ayatana Design
Medium
John Lea
The Sound Menu
Medium
Unassigned
indicator-sound (Ubuntu)
Medium
Unassigned
notify-osd (Ubuntu)
Medium
Mirco Müller

Bug Description

When using the sound menu, the user is immediately visually notified about switching of tracks by the menu itself.

+

When notifying using Notify-OSD, it covers some parts of sound menu itself. I think Notify-OSD should not be shown when switching tracks using the sound-menu and MAY BE whenever switching manually.

Example video:
http://dl.dropbox.com/u/275756/out.ogv

PS:
U1 was not working, so dropbox. :)
and yes, I did spend like 10 minutes thinking which songs I should show in the video. :P

Tags: udp Edit Tag help
Mirco Müller (macslow) wrote :

There's a small catch we've to think about. The time of notification-arrival (in notify-osd) and time of display (by notify-osd) is not guaranteed to be close to each other, because of the notification-queue in notify-osd.

With every notification we get the name of the sending application, which we could test that against certain media-players. Depending on the outcome of that check, we could do some method-call via dbus to see if the sound-indicator menu is open (not sure if that's possible though) and skip the display of the bubble.

I don't know how much trouble it'll cause if people skip numerous tracks very fast and we would have all these dbus-calls in between then.

Owais Lone (loneowais) wrote :

What if this is implemented in the music player itself. May be disable notify-osd for all manual commands.
If I click play or forward, I already know this + I get notified automatically when the sound changes so there is basically no point in showing a notification too. Also, on manual commands, the music player's main interface is visible so the change is noticed.

I think music players should notify only when the song changes automatically OR when changed using a hotkey, remotely or IR control. Basically send notification only when the command is not called from main interface or sound menu for everything else send out notification.

Mirco Müller (macslow) wrote :

After some initial discussion it's clear this needs to go through design first. There are to issues...

1.) Placement of bubble and sound menu conflicts.

2.) The same info is displayed at the same time. If the placement (see 1.) is changed, then there's a problem with the same information being displayed at the same time in different spots on the screen. This redundancy should be avoided.

Design please advice.

Conor Curran (cjcurran) on 2010-10-01
Changed in indicator-sound:
importance: Undecided → Low
assignee: nobody → Conor Curran (cjcurran)
status: New → Confirmed
Conor Curran (cjcurran) on 2010-10-01
Changed in indicator-sound:
importance: Low → Medium
Vish (vish) on 2010-10-03
Changed in indicator-sound (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Conor Curran (cjcurran) on 2011-03-01
Changed in indicator-sound:
status: Confirmed → Triaged
Victor Martinez (victored) wrote :

Moreover, notify-OSD should have a classifying system based on importance (or priority). In fact, an application should be able to tell notify-OSD "send this unimportant notification", so in case that notification could interfere in any way the user, the notifications system won't show it or instead will show it in a different position of the screen (such as the bottom right corner, only if the notification won't be obtrusive there). For example, if the menu of an indicator is opened [and the notification would be obtusive], IMO there are two ways to handle the problem:

 1 - Show it right down the menu, where it won't interfere.
 2 - Wait until the user closes the menu and then show it only if it was sent as important.

Here's a list of notifications I consider important:

 - Ubuntu One status notifications
 - New mail/message
 - Low battery

... and the not-important:

 - Current-Song notifications.
 - Network status (except for public networks and when the user is offline).

Whishlist:

 - The ability to set the importance of notifications based on it's type. Both users and developers should be able to set the values/types.

Conor Curran (cjcurran) wrote :

It seems that with the upcoming notify-osd work in this coming cycle there will be scope for doing the necessaries within notify-osd to make this happen.

Changed in notify-osd:
assignee: nobody → Mirco Müller (macslow)
importance: Undecided → Medium

I think that the suppression should happen when any indicator is opened... So I'd give this role more to the desktop (unity) than to each indicator.

Changed in indicator-sound:
status: Triaged → Confirmed
Changed in indicator-sound (Ubuntu):
status: Triaged → Confirmed
Eric Zig (zuric) wrote :

I'm agree
For me, it's will be awesome if we have this behavior: http://ubuntuone.com/36gSZxfwib9tJQZ2mBMyEi

While the Sound Menu is not open show the notification else disable the Notify-OSD

John Lea (johnlea) on 2012-01-30
Changed in ayatana-design:
assignee: nobody → John Lea (johnlea)
importance: Undecided → Medium
status: New → Triaged
Changed in notify-osd:
status: New → Confirmed
tags: added: udp
Changed in ayatana-design:
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in notify-osd (Ubuntu):
status: New → Confirmed
Kai Mast (kai-mast) wrote :

Guys, this bug is open for over a year and makes switching songs with indicator-sounds unusable.. Why is this not fixed yet??

Mirco Müller (macslow) wrote :

A fix for this does not require any work on the side of notify-osd. notify-osd actually has no knowledge of what goes on around its bubbles on the screen. Thus tring to "fix" it from that angle is fundamentally wrong.

When the song-switch is triggered via the sound-menu, it should not issue a notification.

Since the notification for the song-switch is coming from the music-player application (rhythmbox or banshee), there needs to be an added "flag" those apps expose to the sound-menu, which reads like "don't trigger an notification".

With such a flag in place and correctly interpreted by the music-players, it'll be easy for the sound-menu to suppress any notification.

John Lea (johnlea) on 2012-10-15
Changed in notify-osd:
status: Confirmed → Triaged
Changed in indicator-sound:
status: Confirmed → Triaged
Changed in notify-osd (Ubuntu):
status: Confirmed → Triaged
Changed in indicator-sound (Ubuntu):
status: Confirmed → Triaged
Changed in notify-osd (Ubuntu):
importance: Undecided → Medium
no longer affects: notify-osd
Changed in notify-osd (Ubuntu):
assignee: nobody → Mirco Müller (macslow)
Changed in indicator-sound:
assignee: Conor Curran (cjcurran) → nobody
Lars Uebernickel (larsu) wrote :

This issue cannot be solved in the sound menu. It is up to the applications to issue notification bubbles based on how the track was changed. Similarly for notify-osd: it doesn't have enough information to decide whether to show the bubble (namely, where the track-changed event was originally from).

I think apps should never show a notification in response to a manual track change, unless the track was changed using the media keys.

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

Other bug subscribers