Replies below...

  _____  

From: Ivan Ooi
Sent: Sunday, January 18, 2009 6:29 PM

 

Nice if able to come out some thing similar to 

http://www.smartclient.com/smartgwt/showcase/#effects_animation_move

[Roland Tepp] Yes, most of the move and resize effects are easily doable. Fade 
in/out are currently not due to the fact that SWT widgets in 3.2 do not support 
setting their alpha values.

 

From: Jeremy Dowdall
Sent: Monday, January 19, 2009 2:51 AM



Hi Roland,

A few of points about the framework that came to mind:

1.      You did mention animating any property on any object, and I want to 
stress that point further.  The document describes a good framework for 
consumers of widgets, but not necessarily for use within widgets, which is far 
more important for a Nebula hosted project, especially as SWT is supposedly 
working on a framework of their own.  The core of the framework really needs to 
be abstracted out to just be a value changing at specific time intervals.

[Roland Tepp] Well – ma reasoning not to limit myself to only SWT widgets was 
born out of the practical notion that there are things I just can not do with 
SWT (like alpha blending, table row item reordering animations, etc.) that I 
might need to emulate on a completely custom drawn widget/layer, so I simply 
did away with any assumptions on what it is exactly that I am animating.

The AP itself is loosely modeled after some examples I saw in dabbling with 
Flash/Flex jQuery and WPF/Silverlight.

At the core there is an abstraction of an animation that has actually nothiong 
to do with anything else than processing animation events like starting, 
stopping, pausing and resuming animations. The animator acts as a sort of a 
concertmaster (or more aptly choreographer) of the whole animation and calls 
frame events on the running animation(s). The only concrete types of animations 
that are defined in the core api are Parallel and Sequence, which provide 
parallel and sequential execution of the animations they contain. And Tween, 
which is an abstract base class for simple „tweening“ animations like Move, 
Resize, Foreground, Background.

2.      Frame dropping.  We can't be guaranteed what else will be going on when 
we try to animate something - if the system falls behind we don't want to waste 
time with frames that are out of date so we'll need a way to identify this and 
gracefully skip them.  I've done this in javascript by giving each initiated 
frame an ID, the animator keeps track of the active ID and if a frame comes due 
with an older ID it simply returns.

[Roland Tepp] To be honest, I have not thought of that aspect, although I 
suppose that with the API I have, this feature should not be all that difficult 
to add...

3.      Cancellation.  Quite often something may start to open and then be 
requested to close before it is finished.  Locking the animation to not perform 
the close until the open is complete is a workable start, but not what is 
intended.

[Roland Tepp] Every animation has four public methods: start, stop, pause and 
resume, so cancelling a specific animation in a larger animation quite possible 
but (in fact, I did just that quite recently and it works like a charm).

4.      Inject runnables right into the chain of events: close_animation -> 
runnable(set text) -> open_animation.  The Listeners you mention can be used 
for this, but something about it seems awkward.

[Roland Tepp] Well – Listeners are designed just for that, but You can also 
just write your own „animation“ class that does nothing else but execute a 
runnalbe (preferably in a separate thread, as all the animation framess run by 
necessity inside UI thread) and once  the runnable finishes, move the animation 
into the „finished“ state.

5.      The pluggable easing strategies look quite flexible, but would they 
allow me to do a completely custom animation path?  Here's some reference for 
this: http://www.w3.org/TR/SVG/animate.html#AnimateMotionElement.

[Roland Tepp] easing strategy is actually nothing else but a function that 
defines the acceleration of the movement across it’s movement path. If you want 
the path to be a curve, you have to write your animation implementation that 
maps one-dimensional „position“ (that Easing operates on) to a point in two- 
(or 3-) dimensional plane. Move and Resize are just simplest of such animations 
(their movement path being linear).






 

_______________________________________________
nebula-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/nebula-dev

Reply via email to