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 _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
