2008/10/27 Paul Louden <[EMAIL PROTECTED]>:
> Jonathan Gordon wrote:
> And you've heard dozens of times it's not *just* bin increase that's a
> problem, but whether a feature's bin increase is worth the functionality it
> adds. There's a finite limit on how much can and should be added (though
> we
Jonathan Gordon wrote:
1. bin increase
Well, As civil as I'd like to be, I think everyone knows my views on
this argument… Its nonsense. What's the point of the project if every
time a red delta happens everyone complains? May as well close up shop
here.
And you've heard dozens of times it's
I think its time to have a proper discussion about adding settings
(and to a lesser extent, adding features which may not be used by the
vocal majority.) I'd like to keep the two topics separate but I don't
think it's really possible.
This is being prompted by XavieGr's email and patch (FS#9455) b
> I don't know (and didn't look at) how the scrolling is coded.
> But wouldn't it in principal be better to avoid such hacks such as "space
> padding" (or any other character)?
>
> Why not code a "waiting time" when the scrolling comes to the end of the
> screen?
> In that waiting time the scrollin
XavierGr wrote:
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.
Personal
Hi XavierGr,
I don't know (and didn't look at) how the scrolling is coded.
But wouldn't it in principal be better to avoid such hacks such as "space
padding" (or any other character)?
Why not code a "waiting time" when the scrolling comes to the end of the screen?
In that waiting time the scrol
