UI long term development perspective: physics engine

Florent THIERY fthiery at gmail.com
Sun Apr 1 15:25:23 CEST 2007

> This paper (linked from that site) was interesting:
> http://www.teknikus.dk/tj/gdc2001.htm

Yes it was :) Still, it's pretty specialized: it's about improving
animation of characters in a videogame; the most relevant part of it
is this so-called Verlet integration scheme, which is exactly what
libakamaru does...


After reading this i realize that's not what we need, simpler
equations will suffice completely.

I'm wondering what layer of openmoko has to be hacked, i.e. if working
at openmoko layer allows enough possibilities for this; if i'm not
mistaken, this is part of libmokoui, but i'm pretty afraid that
patching gtk itself woud be needed. Working on the lower level would
apply changes to every application, not only openmoko's.

One preliminary idea can be to add inertia and friction to the finger
scrolling wheel; which means, you launch the wheel, and stop it when
you like. For instance, one complete wheel turn = one element in the
list further. This is an interesting option, because it only needs
modification of the wheel's function and graphics effect.

Nevertheless, there are different approaches. Example (it's merely an
iphone "imitation", so if you have novative ideas, please add your 2

**********Scrolling: the "wheel of fortune" effect (i can't find a
better example than
: imagine that every item of a scrollable list isput on the front
surface; the aim is to reach this
http://www.youtube.com/watch?v=nPqqfVLQ_qY )

Forget the slider bar for scrolling windows, and let the entire window
be scrollable by default

* Sliding = Single click + maintained for a minimal distance
Effect: scroll in an inverted/negated fashion (slide down = scroll up,
slide up = scroll down)

When finger is released (i.e. touchscreen doesn't detect any press):
   if (last_speed_seen > value ) then keep this speed and
acceleration, with friction (so that it slows down)
   else stop scrolling

Scrolling here is seen as unidimensional, but can apply to
bidimensional situations (ex: zoomed image) too

* Action = quick double tap

* Details/select = short single tap

* Right click = long tap

* Gestures can be interesting, especially for "jumps" (when the cursor
jumps from upper left corner to down right)

> Obviously the tools are in the wild to build interfaces that could rival
> (or better IMO) anything Apple comes up with. We just need to organize
> this stuff. This would need hardware that can support dynamic
> interfaces. I can help here, too.

Well, considering recent changes in destkop applications, opengl has a
definite future. For instance, the expose (be it apple's or beryl's)
is a very interesting and usable feature. Using compositing allows the
physics metaphore: the human brain doesn't like "gaps"/jumps (for
instance while scrolling a text), it needs continuity. When you look
at apple's iphone prototype, it's not just eye candy, it's maybe the
most natural/human way of navigating, because it's sufficiently
realistic for the brain to forget the non-physical nature of what's

So, opengl hardware will be needed in a more or less distant hardware,
for 100% fluid operation.

And, if we really want deep changes, multi touch screen if essential
too :(  (example: zooming with fingers)...

> So does anybody want to start this? I mean _seriously_ start this. I'm
> more than willing to fund development if I see a plan in place.

I'l be glad to work on the planning in the wiki, i.e:
- assembling knowledge about the location of the code areas to  modify
(but it's in libmokoui for now)
- assembling ideas such as scrolling
- assembling UI resources/papers/libs etc...

But, that's true, wee need a really good, novative idea. So.... Brain
up, community !


More information about the community mailing list