> > 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.
You're probably right, we should wait for DUI to become stable, so that we could just extend it to fit our purpose. > these are already themable, really. nobody seems to care, but then we have > pretty simple anims so there's not a lot to interpret differently. Or nobody seems to know :) As for 'does animations belong with the themes' question, I think yes - both are about controlling the visual part of it all. But, as I said, we should probably wait for that - so that we don't have the need to support both our old descriptive syntax and the new (Troll's) one. The reason I proposed the descriptive language is that the proposed ideas: >Animation *a = Animator::fadeIn(item); >Animation *b = Animator::add(a, Animator::bounce(item, timesToBounce)); >a = Animator::while(b, Animator::blur(item, amount)); >Animator::add(a, Animator::fadeOut(item)); >// auto starts when event loop is hit again, unless a->stop() is called >Animation *a = Animator::fadeIn(item); >Animator::bounce(item, timeToBounce, a, Animator::Add); >Animator::blur(item, amount, a, Animator::While); >Animator::fadeOut(item, a, Animator::Add); have a really uncute syntax - it simply is not readable. The original idea is better looking (to me), but it will mean exposing two more classes to script engines, while (if I understood it correctly) those classes are not yet API/ABI stable. >QAnimationGroup g; >g.addAnimation(Animator::bounce(item, timesToBounce)); >g.addAnimation(Animator::blur(item, amount)); > >QSequentialAnimation s; >s.addAnimation(Animator::fadeIn(item)); >s.addAnimation(g); >s.addAnimation(Animator::fadeOut(item)); Cheers _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
