UI long term development perspective: physics engine

[Florent THIERY]

> This is interesting - even if you just want a smooth scroll action you still
> need to relate it somehow to machine time (bad approximation of real time)
> and some time constant. It might be most efficient to group all those
> functions into a library rather than have lots of apps each doing these
> calcs independently each using the time system calls.

Exactly. It could be interesting to develop a lib dedicated to UI
animation. I took finger-based scrolling as an example, but the same
can apply to popups (such as calling event), in-gallery (image / mp3)
finger-based navigation, map (displacement, rotation)/zoomed
image/zoomed web page navigation, wheel-based menu control ...

Acceleration has to be taken into account: you slide your finger with
a defined (linear should be enough) acceleration, initial speed, and
these vectors have to be measured and reproduced in the scrolling
behaviour. If i recall my (long abandonned) physics courses well, just
second degree movement equations, should be quite easy to modelize.

The difference with traditional scrolling is that the menu/image has
to continue moving on it's own even when you don't touch it, with some
friction (so that the movement stops by itself after a certain time).
In fact, we have to modelize a "wheel of fortune" (for scrolling), and
a "floating sphere" for image/webpage navigation.

Simple question: will the touchscreen be 0/1 or does it have basic
pressure reporting?

In fact, such a lib may be closely related to handgesture recognition.
The thing is: can reliable gesture recognition be done without
multi-touchscreen?

> If you start a project I will help - I am a simulation engineer used to
> modeling fluid dynamics, chemistry and electricity.

:) I don't think i'm gonna start anything before owning a device, and
i'm not sure i'll get a pre-version. So i'll let you start. Anyway,
that's the spirit !

Florent