Feedback wanted: Improvements to current Qt Widget/style mechanism

[Marco Martin]

On Tuesday 06 April 2010, Artur Souza (MoRpHeUz) wrote:
> Hello!
> 
> We had some talks about this during Tokamak3 (in Switzerland) and we
> collected the feedback, thought about some solutions and came up with this
> proposal. It's also important to say that we want to do everything related
> to this subject as open as possible and that's why we're including you
> since the beginning of the discussions :) So please, give us some feedback
> and help us improve the state of the art of Qt's widgets/styles.
> 
> > Hi,
> > 
> > We are writing to get some feedback from you in the context of a proposal
> > to improve current widget/style mechanism of Qt.  We would like to ask
> > you to read
> > this and provide feedback, in particular by answering the last three
> > questions.
> > Keep in mind that all of this is work in progress, and even though we
> > wrote some
> > experimental code, there's nothing "written in stone".
> > 
> > == Reason ==
> > Developers that want to customize the UI and/or behavior of existing
> > Qt widgets (QWidgets or QGraphicsWidgets) are not able to do that with
> > QStyle,
> > or don't want to, either because it uses an outdated procedural painting
> > approach or because it is not flexible enough.
> > 
> > As a result, many people writing rich UIs are writing their own widgets
> > instead
> > of using those available in Qt. However this process is time-consuming
> > and leads
> > to the creation of code that is duplicated and prone to bugs.

this actually happens for two reasons:
to change the look is one, but i have more often seen it done purely to 
enhance functinality, so what would have needed to be changed is the model 
side.
any solution should allow both use cases.
so, to do a simple example let's say that the default pushbutton model doesn't 
allow to have a menu on press (i know it will, just an example)
so, in order to have a pushbutton with menu i have to:
a) subclass the pushbutton model, to add the menu manipulation into it
b) subclass the visualization to let's say add an arrow that indicates it 
expands.

> > 
> > The Qt Components project was born to provide a better solution for those
> > willing to customize the look and feel of C++ widgets as well as to
> > provide an
> > easier way for Qt Quick developers to handle the boilerplate code of
> > their UI.
> > 
> > == Proposed solution ==
> > 
> > Our proposed solution has the two following parts:
> > 
> > -- Models --
> > 
> > The first is a set of UI-independent models (back-ends) that will hold
> > the boilerplate logic currently found inside the technology-specific
> > widgets (QPushButton, QSlider, etc)
> > 
> > What we want to solve here is the separation between what is:
> >  - look and feel: How does this button respond to a hover event?
> >  
> >                   What is the click area of it?
> >                   Is this slider shown as a bar or a twisting knob?
> >  
> >  - state and logic: The mouse went out and in the mouse area, is that a
> > 
> > click?
> > 
> >                     This button is inside a mutual exclusivity group,
> >                     which button should I uncheck when this one is
> >                     checked?
> > 
> > The benefit is that Qt Quick designers can use this "button backend" to
> > handle
> > the developer-oriented logic and focus on what matters, UI.
> > 
> > Also, if we have widgets implemented as QWidgets for instance, it becomes
> > easy
> > to implement their QGraphicsWidget or QDeclarativeItem counterparts,
> > without duplicating the code.

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)

> > -- Style --
> > 
> > The second is a new styling mechanism that is flexible enough for rich UI
> > applications to use and that fits the existing technologies as well as
> > the upcoming ones.
> > 
> > The main reason for creating a new style system in Qt is to use a
> > primitive-graph approach over the existing procedural painting. That
> > means the
> > style will be responsible for hooking a group of primitives (image, text,
> > rectangle) in the about-to-be-styled widget, rather than actually
> > painting parts
> > of it.
> > 
> > That way we have more flexibility over how to style the widget, and it
> > becomes
> > easier for the canvas to automatically cache painted primitives.

yeah, this is a good thing

> > We came up with an architecture that uses the following concepts, that
> > are somehow independent and that we would like to hear feedback about.
> > 
> > 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?

> > 
> >    Example: When populating a Button the style creates two background
> >    
> >             primitives (one for pressed, one for released) and one text
> >             primitive for the button label.
> >    
> >    That probably looks fine, but raises a question, what would happen
> >    when the button label changes? How would the primitive be updated?
> >    The same holds for a button press, how would the background primitive
> > 
> > know
> > 
> >    about that?
> >    
> >    We do not intend to create an "updatePrimitives" method or something
> > 
> > that would require the widget state information to flow through the
> > style. Neither
> > 
> >    we wanted the Button to assume/expect anything about the primitives it
> > 
> > has.
> > 
> >    To keep that decoupled, we would rather use the "data binding" concept
> > 
> > from
> > 
> >    Qt Quick. That means when the style populates the button for the first
> > 
> > time
> > 
> >    it would create a binding between the "label" property exported by the
> > 
> > button

who would decide what the binding is?

> > 
>> snip
> > 
> > We would like to hear what you have to say regarding whether that looks
> > reasonable to you and:
> > 
> > 1) Do you understand that it would reduce the need for 3rd party styling
> > 
> >    infrastructure implemented on top of Qt?
> > 
> > 2) Would reduce the need for reimplementation of existing widgets?
> > 
> > 3) Would reduce the workload and/or amount of duplicated code for those
> > 
> >    implementing 3rd party widgets? (e.g. KPushButton vs QPushButton vs
> >    Plasma::PushButton)

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

Cheers,
Marco Martin