• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category User Interface → Themes
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 1
  • Private
Attached to Project: Rockbox
Opened by nicolas_p - 2007-01-04
Last edited by Llorean - 2008-01-16

FS#6505 - Slider progressbar

This patch adds the %S|filename.bmp| WPS tag to allow displaying a slider bitmap instead of the regular progressbar.
It works exactly like %P|filename.bmp| (bitmap progressbar), but instead of displaying just a part of the specified bitmap, it will display it entirely at the right place to show the progress. was the inspiration for this quick patch.

Closed by  Llorean
2008-01-16 14:16
Reason for closing:  Duplicate
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

%px should cover this functionality in a much more flexible way.

(forget this)

Included in my build: Thanks Nicolas!

While listening to a 146MB, 64kbps, 32000hz, 5:19:00(roughly) file the slider progressbar disappeared at the 3:36:00 – 3:37:00 mark. It would stay gone until the end of the file. When the next file played it would appear again.
Tried with another different file(almost exact same attributes as above) and same thing occured.

I have a Gigabeat F20, Jan 27th build. No other patches applied. Custom theme(my own), BMP heavy. If any other info is required just ask.

I’d appreciate it if someone else tried to recreate this bug as well to collaborate with my own account.

Thank you & special thanks to the developer of this patch, I really dig this patch

Flake commented on 2007-02-09 23:21

does it work with old style progress bar also?

Flake: No, it doesn’t. That would be a different thing to implement in the code.

Here is another version that *should* solve the problem described above.

Previous version didn’t solve the problem. This one does.

Ah jeez…. Sorry Nic but I think I found a bug, maybe.
I have a Gigabeat F20, Build is March 4.

The Progress Bar goes slightly past the point where I defined it to stop.
I remember the old version didn’t go this far cause I explictly remember making the point where it stops one pixel less cause that was the way I wanted it.

Forgot to add… If you don’t feel like fixing this I’ll totally understand and still want to thank you for making this nifty patch.

Needs A sync

I just had to say a big fat thank you to Nic for making the patch and Max for syncing it. Now it’s absolute perfection needs no correction.

Needs another sync please. Started failing on the 11th of November.
Also if you want to fix it there’s a bug where if the time goes past 3:33:33 the graphic for the progressbar disappears. After about 5 hours it starts to appear on the left of the screen.

To be honest, i think this task could be closed now, as the recent-ish change to the progressbar to allow conditionals ( allows this same functionality.


The song percentage tag does have it’s strengths (ie. vertical progress, curved progress) but because you have to plot the path of the progress it will never be as smooth as this patch. Also if you did try to replicate this patch with the tag it’s possible you may run out of letters to use for the conditional.

With this patch you simply state start from point A and stop at point B.


Available keyboard shortcuts


Task Details

Task Editing