The idea is to reify animations as strategy objects, that can be accessed
and run from any Morph, centralized in an MorphicAnimationsRunner class, (
to avoid pupulating Morph with extra methods, similar to Seaside "brush"
You can try it out via the examples, MorphicAnimationExamples class.
Integration with the SystemWindow is provided also, if you enable the
animate windows setting you can give it a try.
I think this could be integated into Morphic, as Morphic-Animations
Class comments? Sure, for most they're somewhat self-explanatory, but for
say, SlideAnimation, it would be nice to know what unit the delay is in,
and what it actually does.
There's also no common interface (that I can see) for adjusting the speed
of the animations.
AnimationsRunner animateZoomOutOf: .... smells bad.
There's no corresponding ZoomInOf: ..., and why isn't it just zoom: aMorph
in the first place, where new extent determines whether it is a zoom in or
a zoom out?
AnimationsRunner class >> #uniqueInstance
Why does it use super?
Some WindowAnimation subclasses are in -Core, others in -Windows
Some animations take responsibility of all drawing up to the point where
you copy the bits to the canvas, while others use existing methods in other
parts of the system. Personally, I'd prefer a consistent approach in what
is the Animations responsibility (having everything self-contained would be