Hi; On Tue, 2007-11-13 at 19:14 +0100, Christophe Dehais wrote: > > Having tried myself to replicate coverflow first completely from > scratch and lately using clutter, I would qualify the experience as a > great test of the abilities and ease of use of an advanced 2.5D and > animation toolkit. Indeed implementing a coverflow-like browser with > _all_ the little subtleties that are present in the Apple > implementation stresses many things: > - the animations are not as simple as one's may think at first sight > because cover flipping motions adapt (duration and motion) depending > on how many covers are being flipped at a time.
Indeed. Neal came up with various versions. > - all the animations need to be interruptible (for maximum reactivity > when the user decides to go backward). This is something clutter > doesn't really ease atm. I'm trying to see if I can come up with some > general API for this. In theory at least behaviours should be able to handle this (having there parameters changed at 'runtime' and adapting). However Im not sure how well theory holds. Alternate ideas, modifications would definitely be very interesting. > - At least on the mobile version of Coverflow, the shelf of covers > reacts with some inertia. Stresses some basic physics capabilities. Yes, though Im not sure a 'real' physics engine is used in cover flow, we do plan to integrate some kind of physics engine into clutter post 0.6. > - with several thousands of covers, loading times can become quite > long and texture memory fills up quickly. A texture-proxy kind of actor that essentially just paints a rectangle when its texture is not loaded should fit here. > > I guess all these things might be encountered in many other > non-standard UI, Now to what extent the toolkit need to help for these > ? > As much as possible in Clutters case - that would be the eventual aim. Many thanks; == Matthew -- To unsubscribe send a mail to [EMAIL PROTECTED]
