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