Notifications should be suppressed when indicators open

[Owais Lone]

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

The equivalent for the volume slider is bug 1389761.

[Mirco Müller (macslow)]

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)]

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)]

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.

[Victor Martinez (victored)]

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)]

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.

[Marco Trevisan (Treviño) (3v1n0)]

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.

[Eric Zig (zuric)]

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

[Launchpad Janitor (janitor)]

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

[Kai Mast (kai-mast)]

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)]

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.

[Mark Shuttleworth (sabdfl)]

... and patches welcome ;)

[Lars Karlitski (larsu)]

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.

[Robie Basak (racb)]

Came here to file a bug about the sound indicator on my Aquaris phone obscuring itself when adjusting volume with the popup that appears when I do it. I think this is essentially the same issue as this bug and similarly redundant.

> 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.

In this case, it's about the volume change which is triggered from the indicator itself, so I think this would be a valid task to fix in indicator-sound?

[Launchpad Janitor (janitor)]

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

[Matthew Paul Thomas (mpt)]

Mirco, Lars:
(1) How is an app supposed to know whether a track change was triggered from the sound menu, or from any other software that sends MPRIS requests?
(2) Volume changes aren't triggered by apps. If indicator-sound isn't the appropriate home for the volume changes part of this bug, what is?

[Matthew Paul Thomas (mpt)]

The problem with volume notifications specifically is bug 1447917 and bug 1389761.

One possible solution for this is that all synchronous notifications should be suppressed, and all asynchronous notifications should wait, while *any* menu is open.

[dobey (dobey)]

Moving this to unity. The indicators just export menu structure, and don't have knowledge of when the menu on the renderer side is open, or what the position would be.

[Marco Trevisan (Treviño) (3v1n0)]

It's not up to unity to request the notification, but to indicator-sound.

However, it can have an idea about what has changed by monitoring unity-panel-service status.
Probably this can be done in notify-osd, though... By always delaying pop-ups when an indicator menu is open.

[Ted Gould (ted)]

On Thu, 2017-01-12 at 16:00 +0000, Rodney Dawes wrote:
> Moving this to unity. The indicators just export menu structure, and
> don't have knowledge of when the menu on the renderer side is open,
> or
> what the position would be.
The indicators get an action that is fired when the indicator is opened
and closed on the root of the menu structure if requested. The sound
indicator does suppress notifications when the menu is open. Easy way
to check is to use the scroll wheel on the sound indicator, and then
open the menu and use the scroll menu on the slider (unity7).