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:
- 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.
- 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...
- 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).
- 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.
- 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).