next track button not ghosted when there's no next track

Bug #632956 reported by Sam L. on 2010-09-08
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ayatana Design
The Sound Menu
Won't Fix

Bug Description

This is in regards to using Rhythmbox with the new sound menu.

What I expected to happen: As only one song was in the list of songs for an artist, I expected the next track button to either start playing the first song from the next artist, or to be ghosted out completely.

What happened instead: Next track button was clickable, a click resulted in no song being selected or played. It simply went to a "blank entry" i.e. filler art and no track information.

Conor Curran (cjcurran) wrote :

Thx for the feedback,

yes this scenario does need to be handled properly.

Changed in indicator-sound:
importance: Undecided → Wishlist
status: New → Confirmed
assignee: nobody → Conor Curran (cjcurran)
Conor Curran (cjcurran) wrote :

For now I have handled this by removing the metadata widget from the menu when the user clicks on next and the player returns an empty track data hash.
A ghosting effect would be very nice, using the mpris2 api does could be achieved.


Conor Curran (cjcurran) on 2011-02-09
tags: added: design
Conor Curran (cjcurran) on 2011-02-09
Changed in indicator-sound:
assignee: Conor Curran (cjcurran) → Matthew Paul Thomas (mpt)
Matthew Paul Thomas (mpt) wrote :

In all four players I just tried -- Banshee, Amarok, Rhythmbox, and Clementine -- the Next button is available while playing the last track in a playlist. In Rhythmbox when Repeat is on, and in Banshee and Amarok, it loops around to the start of the first track. In Rhythmbox when Repeat is off, and in Clementine, it stops playback.

I think what an application's Back/Previous and Forward/Next buttons should do in the menu should be consistent with that they do in the application, which is up to the designers of that application. That means I've probably overstepped the mark in defining what the buttons in the menu should do as much as I have. <> If there's a way for the menu to just tell the application "navigate previous", "navigate next", "rewinding ... still rewinding" and "fast-forwarding ... still fast-forwarding", and leave it up to the application to decide what it does in response, I would prefer it if we just did that.

Separately, as I've written, applications should be able to make the Back and/or Forward buttons insensitive when they think it appropriate. Though if that's not possible already, it's probably a low priority since those four major players don't need it.

Changed in indicator-sound:
assignee: Matthew Paul Thomas (mpt) → nobody
Conor Curran (cjcurran) wrote :

Ideally the work around this should be done but in reality players don't exhibit this sort of behaviour, putting this at the bottom of my list.

Changed in indicator-sound:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers