Bug 11320 - Now Playing song progress bar text "skips"
: Now Playing song progress bar text "skips"
Status: NEW
Product: SqueezePlay
Classification: Unclassified
Component: Now Playing
: unspecified
: PC Windows Vista
: -- minor (vote)
: Future
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-10 18:39 UTC by ndijulio
Modified: 2011-11-06 23:25 UTC (History)
3 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ndijulio 2009-03-10 18:39:07 UTC
The numbers for 0:00 and -0:00 jump or "skip" depending on the number.  It is a bug we saw on Jive as well. The net effect is that the numbers appear to be animated.

Another very minor issue is the alignment of the negative "-" symbol.  The FreeSans font type will never appear centered.  We could very easily generate our own negative symbol as an asset for the NP screens.
Comment 1 Blackketter Dean 2009-03-26 17:31:15 UTC
When you say jump/skip you mean that they move spatially, not that the values change unexpectedly?  That's because the digits are not all of fixed width.  Tom: is there a way to force this?
Comment 2 ndijulio 2009-03-26 17:34:50 UTC
Correct, move left to right.  We saw this on Jive too.  

I would be tempted to have the numbers 12:34 be individual elements that are grouped together if that will achieve the right effect.  The same problem would occur for digital clocks too.  So the engineering work would be worth it!
Comment 3 Blackketter Dean 2009-03-27 17:12:07 UTC
*** Bug 11530 has been marked as a duplicate of this bug. ***
Comment 4 Blackketter Dean 2009-03-27 17:12:52 UTC
The best solution here is to tweak freesans (or the glyph renderer) to force the digits to all have the same width.  This is the traditional solution to ensure numerical columns line up.
Comment 5 Blackketter Dean 2009-07-22 09:02:00 UTC
Moving to the product SqueezePlay because this bug appears to apply to any player based on that application code.  Feel free to move it back if it's specific to the original product.
Comment 6 Richard Titmuss 2009-07-27 01:13:39 UTC
Reset priority before triage.
Comment 7 Ben Klaas 2009-08-26 07:52:55 UTC
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Comment 8 Chris Owens 2009-10-21 09:47:34 UTC
Moving these bugs to P4 to make room for moving P1.5 bugs to P2
Comment 9 Pat Ransil 2009-10-23 05:09:32 UTC
Administrative move of 7.5 bugs. All P2, P3, P4 being downgraded one level. Will then split P1s.
Comment 10 Chris Owens 2010-03-08 11:32:59 UTC
Moving lower-priority bugs to next target
Comment 11 Chris Owens 2010-05-06 15:37:53 UTC
Tom is no longer available to us
Comment 12 Alan Young 2011-11-06 23:25:02 UTC
Unassigned bugs cannot have a priority.