But there are different speeds of scrolling.  Instead of just saying stop it "about a second" after releasing, it would be better to make the deceleration relative to the speed of the scroll.  A very fast scroll should be able to eat up large chunks of a long list, so it _should_ go on much longer than a slower one.

Think of it like spinning a roulette wheel.  A slow spin stops spinning after a short period, while a fast one goes on much longer after you've released the wheel.

Without that runout, the fast scrolling becomes nearly useless.  The simple ability to stop a fast spin by touching again is all that's needed to make it a very useful tool.

I changed this afterscroll behavior in r4419. The afterscoll time is now flick speed dependent. Slower flicks will stop after 1 second. Perhaps we should leave this bug open until we feel we have hit a happy point.

Some background: I originally started with just a single deceleration constant, which didn't work nicely on high vs low speeds when trying different constants (though I need to experiment that again, since it is the simplest solution in code). I then switched to a constant time deceleration so no matter how fast you go the scroll stops after the same amount of time.  Originally this time was two seconds, but there was internal desire to have it last longer.  This constant afterscroll time behavior is somewhat similar to the iphone.

Now, with r4419, I am trying for a hybrid: constant time, adding an additional amount of slow down time based on the speed. So, the slowest scrolls will last about one second and the fastest scrolls will last about 5.5 seconds.

Reset priority before triage.

I disagree with Dean, if it keeps scrolling it's useful for moving around large lists. We need to re-evaluate if the current solution is ok for pld.

Tom is no longer available to us

Unassigned bugs cannot have a priority.