On April 6, 2010, Artur Souza (MoRpHeUz) wrote: > > We came up with an architecture that uses the following concepts, that > > are somehow independent and that we would like to hear feedback about.
each sound more or less plausible, but what are the functional requirements for this system? reading the various proposed methods and "reverse engineering" them, it seems that list is something like: * decouple logic from presentation * scoping, so the logic and/or presentation associated with a widget can be changed on the fly in an app depending on the scope (case given in your email was main UI versus a config dialog) * designer friendly * ability to do CSS styling for QtWebkit (hooray for *proper* native widgets in QtWebkit!) what i didn't see was anything about animaton / state transition requirements and what isn't in scope (e.g. "feed starving children", "improve Qt's model/view painting with delegates"). if you can provide some more insights into the above, then i can probably provide something closer to useful input in return :) -- 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 Development Frameworks _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
