Feedback wanted: Improvements to current Qt Widget/style mechanism

Caio Marcelo de Oliveira Filho caio.oliveira at openbossa.org
Tue Apr 6 23:18:33 CEST 2010


Marco Martin <notmart at 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.


Cheers,

-- 
Caio Marcelo de Oliveira Filho
OpenBossa - INdT



More information about the Plasma-devel mailing list