Bugzilla – Bug 12727
Duration & position bar should be inactive for non-seekable tracks
Last modified: 2010-04-08 17:24:39 UTC
The barthat indicates the current position is also used for seeking. One can touch the bar at the desired position to seek to that place in the track. (a) seeking, as a function, should be disabled for tracks for which canSeek is not set true (see bug 11477); (b) some visual cue should be available to enable a user to determine the seekability of the current track; (c) possibly, there should be some sort of error feedback when attempting to seek in non-seekable tracks.
Thanks for filing this one, Alan. a - yes. b - I believe there is a strategy for this (Noah, can you chime in)? - either change the color of the "dot" in the progress bar or (my vote) remove the "dot" altogether when it isn't movable. c - no error message is needed - the bar just simply shouldn't be there or shouldn't be draggable.
Depending on context: 1. Teal dot (w/ progress bar fill)- means track can be dragged/touched (can seek) 2. Off White dot (w/ progress bar fill) - indicator of position in time (can seek) 3. No dot (w/ progress bar fill) - elapsed time/time remaining (cannot seek) 4. Elapsed time (no bar)
Created attachment 5428 [details] Progress bar - different states legend
I'm not sure that I understand the difference between 1 & 2.
Alan, I believe the teal dot is for touch, and the white dot is for fab4+IR / controller / any other new interfaces. (i.e. you can seek, but only via ff/rew buttons, not touch).
(In reply to comment #1) > b - I believe there is a strategy for this (Noah, can you chime in)? - either > change the color of the "dot" in the progress bar or (my vote) remove the "dot" > altogether when it isn't movable. What good is a progress bar without an indicator? Removing the bar would be better.
Jim: The progress bar would still be "filled" to the correct percentage, and would move accordingly as the track progressed. All we're talking about here is not having a "dot" when you can't drag/manipulate the actual progress. Just have the "fill" in the bar. You know, like every other media player ever invented. When no progress is available AT ALL, and all we have is time elapsed (internet radio etc), then there is no bar whatsoever - just xx:yy time elapsed.
(In reply to comment #7) > All we're talking about here is not having a "dot" when you can't > drag/manipulate the actual progress. Just have the "fill" in the bar. Gotcha. Would you also be adding fill to the existing progress bar, because it's not filled currently? Also keep in mind the progress bar treatment in the 10' interface. It's been said by myself and others that it's very difficult to see the indicator from a distance. The 'dot' could stand to bigger (and/or a different shape). Removing it may only make things worse. A thicker bar in the 10' ui would also help.
Yes, we'll need a "fill" in the bar to make this happen. As for size: There are quite simply tradeoffs in terms of how big the screen elements can be, including the progress bar. There is a ton of data that needs to be displayed, and the progress bar already takes a backseat to things like album cover, track name, volume control, etc. Making all of these things highly visible from 10' away on a 3-3/4" wide screen is tough if not next to impossible. What will probably happen is not an increase in the size of the bar, but maybe an increase in size of the time elapsed/remaining text.
*** Bug 11477 has been marked as a duplicate of this bug. ***
Reset priority before triage.
Reading through this bug, I don't believe there's anything to fix for 7.4. This bug is about changing progress bar styling on Fab4. Retarget for 8.0 On review, this may be tricky to do in a non-hackish way. Doubling estimated time.
moving current p2 bugs to p3 to make room for moving p1.5 bugs to p2
Administrative move of 7.5 bugs. All P2, P3, P4 being downgraded one level. Will then split P1s.
This needs to be implemented for AAC and ALAC native playback. Attempting to use the position bar results in the track restarting. It wouldn't be as bad if it had no effect on playback, but this behavior is very broken.
== Auto-comment from SVN commit #8569 to the repo by bklaas == == https://svn.slimdevices.com/?view=revision&revision=8569 == Fixed Bug: 12727 Description: add setEnabled() method to Slider class to allow a slider to ignore events when Slider:setEnabled(false) is set disable progress bar slider and change style to white dot in NowPlaying when self.player:isTrackSeekable() returns false enable progress bar slider when isTrackSeekable returns true add npprogressB_disabled style to other skins so not to throw error
Note that I was unable to fully fulfill this bug because we don't have all of the necessary assets and we no longer have a graphic designer working on this project. What I've done. For tracks that can't seek: changes style in touch skin to a white dot from a blue one events (including touches) are consumed with no action
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release. If you are still seeing this issue, please let us know!