Actually, its something I've been getting around to for a couple of years - the UI was always written with animations in mind. This was just a push to make it happen.
So here's a bit of a nothing video demoing the opacity target. This is two Background widgets, one inside the other, with an Image inside that. (Background widgets produce a nice background fill and border). There's a 10px margin between each element, so a tree of six widgets all up.
The bottommost background widget has a single animation on it: type=in/out, easing=sine, target=opacity, duration=4s, loop=true. So we can see that the opacity propagates correctly down the widget tree. Not shown is a further test where each widget has a different, non-synced opacity animation. They all get blended together properly.
It takes a single method call to add an animation:
c is the UI context and w is the widget. These are not strange concepts if you know how the UI API works, But via this, multiple animations can be added as you like, and they'll all just do the right thing.
So next up are positioning animations, which I think will mostly be offsets against the whole screen (technically the context) but might also have an option for draw offset animations within a widget's bounds, for slide-in or even auto-scroll effects. I think positioning will be easier than opacity because the layout engine is significantly more flexible than the draw stack (by necessity; layout is hard!).
I'm quite sure that positioning will cause problems with input and probably with layers as well, since it starts to bend the rule that a widget never appears outside the bounds of its parent. I think there's a couple of ways I could possible convince the system that this assumption holds even when it doesn't; we'll see.
Still to come are chained animations (when animation A finishes, run animation B) and completion signals (fire this event/call this method when an animation completes). They're both the same basic mechanism, and not particularly difficult to do.
Code is here:
As you'll see, its not particularly complicated. Most of the work so far is making the UI draw code able to mix in an opacity value without the widgets' draw methods having to know about it.
I like where this going!