UI long term development perspective: physics engine

[adrian cockcroft]

The physics comes in if you give the slider "mass" and intertia. Then
it accelerates and decelerates depending upon how hard you push it and
how much friction there is.

The acceleration is driven by the difference in position of the touch
point and the slider as you move the touch point and the slider lags
the movement. Move the touch point slowly and the slider follows it,
flick it fast and the slider will get a bigger kick, accelerate more
then coast to a halt and have the overshoot that you want.

Adrian

On 3/24/07, Florent THIERY <fthiery at gmail.com> wrote:
> I'll add here sotg from an off-list msg;
>
> In fact we have the position given by the touchscreen : [ x(t) ; y(t) ]
> speed is: [ (x(t') - x(t)) / (t' -t) ; (y(t') - y(t)) / (t' -t) ] -
> friction_factor*(t' - t)
>
> ... Where the friction_factor is in [0 ; 1]
>
> If we want acceleration, then we have to integrate the equation once.
>
> Shit, i gotta look into my college courses, it's terrible how fast it
> fades away :-p
>
> I'm not sure we really need to take acceleration into account.
>
> The changes to bring to the standard gtk scrolling are:
> - consider the list as scrollable (not just the scroll item)
> - change the scrolling "stop" behaviour (when the user stops touching
> the screen) like this: if (last_cursor_speed > 0),
> continue_scrolling(last_cursor_speed)
> - when touching the moving list again, stop the scrolling immediately
> - addition of friction may be a plus, for a more
> "wheel-of-fortune"-like experience
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>