Path FS#9455 has stirred up some discussion on IRC which led to a dead end.
Currently, forward-scrolling (bidirectional scrolling isn't a matter) in
Rockbox pads exactly 3 spaces at the end of the string, to differentiate
between the last and first letters of the string.
Personally, I was quite annoyed by this small gap (especially in the car),
and made a patch to increase it. For me it is a usability problem.
The real problem is that this padding is small and some people loose focus
and cannot understand where the line starts/ends. Given the LCD quality on
some DAPs this can be quite disorienting. Many applications I've seen try to
alleviate the problem with more spaces or various characters to split
'clearly' the scrolling string.
The original goal of the task was to increase the space-padding between the
final and the first letter of forward scrolling lines. The first
implementation was just a hack for personal use. It hardcoded space-padding
at exactly half the viewport. Of course this was deemed too much regarding
After some discussion on IRC, the second take of the task was to make a
setting which the user could select 10ths of pixel-padding. The
space-padding is then calculated by dividing the selection with the font's
width, to get roughly the user's preference.
Finally another idea came up on IRC. The user could enter the string padding
of his preference (via virtual keyboard), because some users would like to
have other characters as padding (e.g the character '+'). The third and
final implemntation of the patch did just that, where a user enters the
padding string "literally" and it is appended to the forward scrolling line.
Additionaly the string is saved on the configuration file just like a WPS
After the patch was refined and ready for commit some developers opposed the
idea of having a setting about scroll padding (either space or string),
because of binsize and/or "settings bloat". The discussion on IRC was
inconclusive because different people with different views, habits and
preferences couldn't, of course, agree. One view was to hard code the
space-padding to something more, but that was opposed by other devs who
wouldn't accept making the padding bigger.
Currently the binsize for string padding is +664 bytes and +372 bytes for
space padding (about half of that for targets without LCD remote for both
So what is your opinion about it? Should it be left as it is, make it a
setting (and if yes which) or just hardcode a greater value? (or something
Received on 2008-10-26