[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Qt Kinetic + Plasma Call For Ideas / Project Plan
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2009-05-28 20:19:47
Message-ID: 200905281419.52597.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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" (application/pgp-signature)]

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]