• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category User Interface
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by PeterD - 2008-08-18
Last edited by sdoyon - 2008-08-19

FS#9297 - scrolling has stopped working in info screen

Scrolling of items in Rockbox info has stopped working.

I have a very large font (ter-u24b) configured on my Sansa E200. I can only see,

System → Rockbox Info → Version: r1831

The speech function confirms the version as r18310-080818.

Closed by  sdoyon
2008-08-19 04:19
Reason for closing:  Fixed

I’d guess this was down to r18309. IIRC, there’s a problem where the list code actually stops voice output (with a shutup() call) in some cases. To work around this, the list is redrawn regularly, but this then resets the scroll position so no scrolling happens. To solve this we need one (or both) of the following mods:

1) All voice handling (including shiis removed from the list code, and handled by speech callbacks. Then the list can have speech implemented nicely without needing redraws.

2) The scrolling code not to reset position when a redraw occurs.

I think (1) is a sensible way to go. (2) is somewhat harder, I believe.

I probably need sdoyon to comment on this before we progress.

I’ve reopened  FS#9167  - the info screen and it’s various requirements have a bit of history that’s worth reading up on. Maybe this FS entry should be closed?

I have no objections to closing this bug, since  FS#9167  has been re-opened.

Voicing the list definitely does not require redrawing.

It’s just I was having it redraw fast to update the time on screen but
did not realize that this was compromising the scrolling.

Pondlife: the previous problem was that redrawing the list used to
also cause the current item to be spoken again. At some point the
redraw frequency was high enough that we hadn’t time to finish
speaking the item before starting again. Someone tried to fix that by
not voicing anything from inside the speak item callback, and that’s
when you noticed that despite not speaking we would still
shutup. Calling the speech callback at high frequency does not make
sense IMO. I have disconnected speaking from the list redraw
case. Speech can still be triggered on a special case basis from the
action callback like we do for the free space scan case.


Available keyboard shortcuts


Task Details

Task Editing