On Wed, Apr 7, 2010 at 7:18 AM, Caio Marcelo de Oliveira Filho <caio.olive...@openbossa.org> wrote: > Marco Martin <notm...@gmail.com> writes: > > Hello Marco, > >> on one hand, i feel in order to succeed the normal qwidgets need to use this >> (so until qt5 their api would be a mis of model and view related stuff), >> but this brings to the question: >> what about subclasses of qwidgets that subclassed it for functionality? (i.e. >> kpushbutton) > > The current KPushButton would not be affected as there will not be a break in > Qt's binary compatibility. See below if you were talking about migrating the > current KPushButton to the new approach. > > >>> > a) Style::populate(Widget, Model = 0) method >>> > >>> > Style classes provide a "populate" method that is called by styleable >>> > >>> > widgets >>> > >>> > upon their construction. The arguments are the widget itself, it will >>> > be the parent of the primitives created by the style, and the >>> > optional >>> > >>> > model (backend) used by this widget. >> >> uh, so would be the primitive qobjects? > > Yes, they have to be at least QObjects because we want to make use of > properties and notify signals in those models. Note that this is the > point of view of the Style, for the Style class, its really not > important the exact type here, only that it is a QObject. > > The fact that it has a more specific type may or may not be important, > if you are populating your widget with a QML component, it isn't, you > simply will load the "Button.qml" with a property 'model' available and > put the model there. > > However, if you're building a C++-based style, you can either use just > the QObject interface, or (in the case of our "populator system") cast > the correct type of the Model that you expect from that widget type. > > >> who would decide what the binding is? > > The Style. That has to do with look and feel, only the Style knows which > primitives should react to changes in the widget/model. And also which > primitives should affect the model and widget (the MouseArea for > instance). > > >> It's a sane approach, however, my concern is how it goes together everything >> it exists right now: >> as i said many qwidget are subclassed for a mix of look and functionality >> requirements, so while wouldn't be possible to change kpushbutton and the >> likes to the new system overnight, even if it wouldn't be necessary to do big >> binary incompatible changes. >> i don't have clear answers, but it should be done in the way it would provide >> the smootherst transition path compared to what we have now > > Our proposal suggests that widgets are implemented in a way that the > "logic" parts are separated. This "logic" parts of widgets can be reused > internally by existing Qt4 QWidgets -- some of those parts even can be > extracted from the Qt4 QWidgets themselves. > > Those parts, if made public, could be used internally by KWidgets as > well. Imagine a "QButtonModel", that could be extended with more > functionality (let's say, KAuth integration) and a KButtonModel could be > created. This KButtonModel could be used as implementation detail of > both KPushButton and Plasma::PushButton. > > We understand that this by itself already is a good thing for KDE, that > uses the entire KPushButton to get the behaviour for > Plasma::PushButton. Even better, if a new "environment" appear (let's > say, Qt make a new canvas or this new Style approach in a future version > of Qt), will be easy to just reuse the logic in KButtonModel. > > For the Style part, we are not so sure if today's QWidget can benefit > from that, but we are trying to propose something that minimize (and in > some cases even reduce to zero) the need of "redoing it all over again > for the next Canvas". > > The graph scene assumption that is in the Style proposal probably will > be still appliable in the "next Canvas", so even if the "basic types" > change, the core of a Style (and of the widgets visual parts) can still > be easily portable. > > > Hope that it clarified a little bit the issue.
Glad to hear that is exactly the idea i had back in January...I think I talked about it to Marius, Artur and Gabriel. Dude seriously I need to come to Recife! > > > Cheers, > > -- > Caio Marcelo de Oliveira Filho > OpenBossa - INdT > > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
