Hello Aaron, > each sound more or less plausible, but what are the functional requirements > for this system?
If we had to say _one_ problem that we want to solve, in a very informal way, that would be: "Avoid the need of every new Qt-based framework/library in town to reimplement a widget and style infrastructure" In particular every new project on top of QGraphicsView had to deal with that, we at INdT had a couple of those projects internally, and publicly we have libdui, UI Extensions for Mobile (aka Orbit) and the Plasma widget set. Even with QML at hand, we understand there's a demand for avoid doing stuff again and again. For example, reimplementing the logic of a scrollbar in QML is clearly possible, but in practice, you don't want to deal with that when developing applications. We think that providing the right set of tools, much of this "rework" and "implementations of basic widget infrastructure" could be avoided. In this context, some points we think are important in order to reach this goal: 1) Decoupling logic from presentation. Marius presented the core of this idea Bossa Conference this year (slides: http://www.slideshare.net/mariusbu/the-future-of-qt-widgets). With this "model" idea for example, it would be possible to have a class with all the information needed to make a pushbutton, that KDE would extend it and could share between Plasma::PushButton and KPushButton for instance. This would avoid having a KPushButton inside a Plasma::PushButton just to use it's logic and change the "view" of the widget. 2) Allow the subgraph approach instead of procedural painting As said in the email, existing QStyle does not fit for that job. 3) More extensible style system A Style system that enables us to take care of WebKit requirements is a big win, making the life easier for QtWebKit simply use the platform style and fallback to a FullCSSStyle if necessary (if the page CSS demands that). A Style system that enables using QML to describe the interface of our widgets (and even use this style in a C++ program). And that enable QML to use QDeclarativeItems that are styled in C++, what people call using "native/platform style" in QML. This relates to our core problem. QStyle wasn't enough for requirements of Orbit and libdui, and they had to build their own style systems. > 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"). Regarding animation/states: it seems like it's something to be implemented by specific styles and/or widgets. The idea here is to provide a Styling mechanism that is flexible enough to support whatever look and feel designers want. That includes animations, but no dedicated infrastructure was thought for that. Cheers, Artur, Caio and Eduardo -- Caio Marcelo de Oliveira Filho OpenBossa - INdT _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
