Feedback wanted: Improvements to current Qt Widget/style mechanism

Artur Souza (MoRpHeUz) morpheuz at openbossa.org
Tue Apr 6 18:39:45 CEST 2010


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.
> 
> 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.
> 
> -- 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.
> 
> 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.
> 
>    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
>    and the "text" property of the text primitive. For the background, it
> would
>    bind the "pressed" property from the button model to the "visible"
> property
>    of the pressed background primitive.
> 
>    Once again, the idea is to use a more designer-friendly concept and
> reduce
>    the style API to a minimum.
> 
> b) Populator classes
> 
>    The standard style implementation is a huge switch/case block to create
>    primitives for each of the supported widgets.
> 
>    Our idea is to use a modular approach where the style have a hash of
>    "populator" classes indexed by widget type. These classes hold the
> actual populate implementation for a given widget/style and are registered
> in the
>    styling system at runtime.
> 
>    That allows for existing styles to be extended to support new widgets,
>    without changing the original style. For instance, a KDE specific widget
>    can be styled by a platform Qt style if KDE register the populator for
> it.
> 
>    It also allows for a better organization of the code and for a fallback
>    mechanism to be in place, where populators are chosen in a best-effort
> basis
>    for each widget.
> 
> c) Style access
>    Applications would have a global style and widgets would use their own
>    style or fallback to the application one. This allows for situations
> where
>    the same widget can look differently inside the same application in the
> same
>    platform (a button inside settings dialog vs button in main screen).
> 
> d) QML and CSS integration
>    While we can still implement look and feel of widgets in C++, using the
> new
>    style system, that might be simply too time-consuming when we have newer
>    technologies like Qt Quick and CSS available.
> 
>    To understand how we could style a widget in Qt Quick, we worked on the
> idea
>    of a QDeclarativeStyle. The idea here is that this specific
> implementation
>    of style does not look for populators in a hash, instead it looks for a
> .qml
>    file in a given directory, to represent a widget.
> 
>    For instance, a designer could create a Button.qml file with all
> primitives
>    and bindings he/she wants, and then the style would simply hook all of
> that
>    in the stylable widget. That means a C++ application could have its
> widgets
>    specified in Qml. It would also allow the opposite, to have Qml
> applications
>    styled in C++ to look like native apps.
> 
>    Webkit developers also want to have widgets that are customizable in
> CSS, so
>    the same approach could be used, a special CSSStyle that loads a CSS
> file and
>    customizes the primitives based on that information.
> 
> == Feedback wanted ==
> 
> 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)
> 
> Cheers,
> 
> OpenBossa - INdT
> http://www.openbossa.org/
--------------------------------------------------------------
Artur Duque de Souza
openBossa
INdT - Instituto Nokia de Tecnologia
--------------------------------------------------------------
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
--------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100406/f8fe58e3/attachment.sig 


More information about the Plasma-devel mailing list