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

List:       kde-panel-devel
Subject:    Re: Feedback wanted: Improvements to current Qt Widget/style
From:       Alexis_Ménard <menard () kde ! org>
Date:       2010-04-10 0:12:32
Message-ID: l2x81941aea1004091712m2bd955ffj966bece7ee40cf7b () mail ! gmail ! com
[Download RAW message or body]

On Wed, Apr 7, 2010 at 7:18 AM, Caio Marcelo de Oliveira Filho
<caio.oliveira@openbossa.org> wrote:
> Marco Martin <notmart@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

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