• Status Unconfirmed
  • Percent Complete
  • Task Type Bugs
  • Category User Interface
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Defer
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by asettico - 2009-08-18
Last edited by jdgordon - 2009-12-16

FS#10541 - Wrong value used when changing scroll bar width

In the "Scroll bar width" screen, the value used to show the width selected is the previous one, not the current one. The first value change has no effect.
Anyway it seems that the right value is stored: if you select a value and exit by the screen, when you re-enter in it, the width is correct.

Priority low.

Referred to r22406.

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 ( and onwards) and concluded as a Won't Fix.

I'll leave this open for now though.

fml2 commented on 2009-08-19 11:03

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, 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.


Available keyboard shortcuts


Task Details

Task Editing