[jaunty] "Next track" notification appears even if nothing listening

Bug #345363 reported by Alan Pope 🍺🐧🐱 🦄
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-settings-daemon (Ubuntu)
Fix Released
Low
David Barth

Bug Description

Binary package hint: notify-osd

Go to System -> preferences -> keyboard shortcuts, define a key for "next track" - I used ALT+N.

Press ALT+N when no audio apps are open, you will see a "next track" style icon in the notification bubble.

Would it not make more sense for notify-osd to check if something is listening and only show the notification if something is?

Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

Is this, perhaps, by design? It's nice that the user gets the feedback that the "next track" key has been pressed.

Changed in notify-osd (Ubuntu):
assignee: nobody → dbarth
importance: Undecided → Low
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-settings-daemon - 2.26.0-0ubuntu3

---------------
gnome-settings-daemon (2.26.0-0ubuntu3) jaunty; urgency=low

  * debian/patches/16_use_synchronous_notifications.patch:
    - don't display stop, previous, next key notifications
      (lp: #351986, #345363)

 -- Sebastien Bacher <email address hidden> Mon, 06 Apr 2009 11:39:37 +0200

Changed in gnome-settings-daemon (Ubuntu):
status: New → Fix Released
Revision history for this message
Damiano Dallatana (damidalla) wrote :

While it is evident that this bug is solved with latest "fix", it does introduce a regression against the desired behaviour of notify-osd in the specs page. Now the hotkey actions are not notified at all (again, bug #343261).
The scope of this particular bug was "only" to make g-s-d wait for a program to listen and act at a hotkey action before making notify-osd show a confirmation notification.

Revision history for this message
David Barth (dbarth) wrote :

Damiano, you're right that the spec does not reflect that. Mpt probably wants to keep it for 9.10, but for 9.04 we cannot make this work properly.

For this part of the specification to work we need to make the change directly at the application level. I haven't found a way for gsd to know when an application has actually acknowledged to change a track, nor if it is going to display a second notification or not. Additionally, it would be nice if the application could let gsd know if it is in play/pause or stop mode, so that gsd can then do the right thing when a toggle key is pressed (most keyboards have a signle play/pause key).

As a result, mpt and I have agreed to revert to the initial situation where we were not displaying an immediate feedback notification, and instead rely on the media player to trigger the notification. It fixes most opened bugs at once, in that:
 * if no media player is present, you will never see a notification, and thus will not expect something to (never) happen
 * if a media player is present and it can play the next or previous track, it will eventually display a notification when it succeeds
 * if there is an issue with the media player, the network, etc., then you kind of know it because nothing happens, and no notification appears -> you know that you have to go and see what the problem is with your media player.

Ultimately, changes should be made at the player level, and gsd should use some kind of remote control protocol like MPRIS does. This is what we plan to do for 9.10 now.

David

Revision history for this message
Damiano Dallatana (damidalla) wrote :

Well, if it is a momentary "regression" (it is not a previous feature, so it is not a standard regression) in order to reach a perfect implementation in 9.10, then it can be surely worth the wait!
BTW, thank you very much indeed for the time you spent in giving such a complete answer :)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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