Rockbox

This is probably because the scrollbar gets drawed with the previous value first, and *then* the new value gets set.

Perhaps a callback triggering a redraw of the current screen could solve this..

This was discussed in IRC ( http://www.rockbox.org/irc/log-20090819#00:01:01 and onwards) and concluded as a Won't Fix.

I'll leave this open for now though.

I'd rather like to have this fixed. Either disable the live update or get it right.

If it becomes a hard to fix problem due to settings list implementation, disabling the live update could be acceptable.
In this case, it's sufficient accept the new value and re-enter in the menu to see the changes.

@mcuelenaere: I tried to investigate somehow the settings list, comparing the behaviour with "Backlight" setting.
In this one, there is a callback function that use the selected value in the right way.
In the IRC discussion you indicated in http://www.rockbox.org/tracker/task/10541#comment32131, I can deduce that a callback doing a refresh of the UI is unacceptable or pointless, is it?

asettico: Right, the fix I proposed was doing a redraw after an item gets selected, but this would result in user select item -> code draws list -> code acknowledges users selection -> code redraws list; and that for *every* list in whole Rockbox.

Also this could lead to a small glitch when going from the maximum scrollbar width to the smallest (the scrollbar would be drawed with the max width and the thumb at the top, then redrawed with the thumb at the bottom and then redrawed with the smallest width and the thumb at the bottom; the correct behaviour should leave out the second draw).

Thomas Martitz (kugel) proposed adding another flag (F_LIVEUPDATE) which would do all the above only if that flag was added, I tend to agree with him although that glitch is still there (but this is very minor).

Confirmed, this is still an issue. Even more interesting when going through the list the original value always seems to produce a wrong width being shown.