On Thursday 28 May 2009, Ivan Čukić wrote: > > neat idea; would require a small parser on our side, but it wouldn't be > > an overly complex one. what would the benefits be? > > - simpler syntax - no need to do addAnimation(blah blah) for each > /animation atom/ > - no need to pass the item variable to be animated into every animation > atom (Animator::fadeIn(item), Animator::fadeOut(item)...)
this comes at the "cost" of control flow type statements. nothing major though. for stuff this simple it's sort of 6 of one and half dozen of another. i'm not sure the learning curve is all that different either way, and it would be a bit nice to not have our own parser unless there's significant benefit? > - complex animations are loaded from a simple text description - easy plug- > ins, easy-runtime changes (if we needed them). these chainings would be pretty widget- and interaction-specific though, no? it makes sense to make the stock animations themable, but custom chains of them? > And, Trolls are already making declarative UI, so this would go perfectly > alongside that. that's actually a concern of mine; we're already going to be getting a DUI at some point, not sure we want to create a "simple DUI" of our own. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
