Bugzilla – Bug 428
Individual scroll rate/delay settings for large and small fonts or a ratio of ~2.
Last modified: 2008-12-18 11:54:02 UTC
Large scroll speed seems to be the same speed as small in terms of VFD 'dot velocity'. However, since the font is about twice the size it should be about double the rate of small to reflect the speed at which text characters scroll by. Similarly the delay should be ~1/2 before scrolling starts. The most flexible would be separate settings; the easiest would likely be the fixed ratio. See bug https://bugs-archive.lyrion.org/show_bug.cgi?id=265
Created attachment 57 [details] new prefs for double rate This patch adds a pref for double rate, and happens to clean up a bit of animation code mess left from legacy. scrollDouble can be used a lot more than it had been in past nad it avoids artifacts and an odd lag at the end of a doublesize scrollBottom. Try this out, Daryle and let us know if this works well for what you desire.
Dumb question: Should this patch be in the latest nightly or do I need to try and do the diff myself? Have to dig up a tool for XP and dust the crud off my diff skills if the latter.
I was hoping you could test it out. However, if Dean ok's committing it, I'll do that and you can let us know if you like the nightly.
committed July 16, 2004
I just tried it and it seems to work great. For completeness/consistency however it might be good to have the corresponding 'Double-Size Scroll Pause' if it is just a matter of a bit more cut 'n paste. The reasoning behind this is the same since there is less than half the text to read the pause need not be as long. Of course if this involves significant reprogramming than it is probably not worth it.
this bug is fixed. if you want a new request, please open a new bug.
Not to be pedantic but the bug refers to both the scroll rate and delay settings. Wouldn't another bug with the delay setting only be a confusing duplication since they go together?
some ppl need everythign done for them...now its reopened, so that people will SEE it.
Unh? I'm a little taken aback by this reaction and not sure what I said to upset you. I was just suggesting that either the bug be reopened to do the delay setting or, if it involves significant reprogramming, it is probably not worth it so just leave it closed. Of course I could have reopened it myself but I thought I would leave it up to your judgement of the difficulty of the other aspect of the bug. I'm completely fine with the position that the delay part may not be worth it but if it is I wasn't sure it should be opened as another bug. Anyhow I'm sorry for any misunderstanding; I'm just trying to help with development suggestions.
you haven't. it was just in the interests of clarity. rate is fixed, so this bug doesnt really apply. being marked as fixed, means a default search doesnt' find it. I think what I'll do is close this one and repoen a new bug with just the one setting to be clear going forward. I'll put you on the CC for it, so that you are part of any tracking.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.