Feedback wanted: Improvements to current Qt Widget/style mechanism

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


Hello Aaron,

> each sound more or less plausible, but what are the functional requirements 
> for this system?

If we had to say _one_ problem that we want to solve, in a very informal way,
that would be:

"Avoid the need of every new Qt-based framework/library in town to reimplement
a widget and style infrastructure"

In particular every new project on top of QGraphicsView had to deal with that,
we at INdT had a couple of those projects internally, and publicly we have
libdui, UI Extensions for Mobile (aka Orbit) and the Plasma widget set.

Even with QML at hand, we understand there's a demand for avoid doing
stuff again and again. For example, reimplementing the logic of a
scrollbar in QML is clearly possible, but in practice, you don't want to
deal with that when developing applications.

We think that providing the right set of tools, much of this "rework" and
"implementations of basic widget infrastructure" could be avoided.


In this context, some points we think are important in order to reach
this goal:

1) Decoupling logic from presentation.

Marius presented the core of this idea Bossa Conference this year (slides:
http://www.slideshare.net/mariusbu/the-future-of-qt-widgets).

With this "model" idea for example, it would be possible to have a class with
all the information needed to make a pushbutton, that KDE would extend it and
could share between Plasma::PushButton and KPushButton for instance. This would
avoid having a KPushButton inside a Plasma::PushButton just to use it's logic
and change the "view" of the widget.


2) Allow the subgraph approach instead of procedural painting

As said in the email, existing QStyle does not fit for that job.


3) More extensible style system

A Style system that enables us to take care of WebKit requirements is a
big win, making the life easier for QtWebKit simply use the platform
style and fallback to a FullCSSStyle if necessary (if the page CSS
demands that).

A Style system that enables using QML to describe the interface of our
widgets (and even use this style in a C++ program). And that enable QML
to use QDeclarativeItems that are styled in C++, what people call using
"native/platform style" in QML.

This relates to our core problem. QStyle wasn't enough for requirements
of Orbit and libdui, and they had to build their own style systems.


> what i didn't see was anything about animaton / state transition requirements 
> and what isn't in scope (e.g. "feed starving children", "improve Qt's 
> model/view painting with delegates").

Regarding animation/states: it seems like it's something to be
implemented by specific styles and/or widgets. The idea here is to
provide a Styling mechanism that is flexible enough to support whatever
look and feel designers want. That includes animations, but no dedicated
infrastructure was thought for that.


Cheers,
  Artur, Caio and Eduardo


-- 
Caio Marcelo de Oliveira Filho
OpenBossa - INdT



More information about the Plasma-devel mailing list