[Development] Notes from the QWidget session

[gunnar.sletta at nokia.com]

On Jun 29, 2012, at 3:50 AM, ext Alan Alpert wrote:

> On Tue, 26 Jun 2012 12:56:06 ext Harri Porten wrote:
>> Here are my notes from the QWidgets session on June 22th, 2012, 11:30
>> o'clock:
>> 
>> http://qt-project.org/groups/qt-contributors-summit-2012/wiki/QtWidgets
>> 
>> ,,,
>> 
>> Help with migration from Qt 3/4 to 5
>> ====================================
>>  - Desktop QML components (using QStyle)
>>  - Wrap QWidgets in QML container element
> 
> That's not going to be quite as easy as the inverse. While I think QML needs 
> to be embeddable inside a QWidget scene for 5.0, there are a couple problems 
> with the inverse so it will probably be a while until that works. See 
> examples/declarative/cppextensions/qwidgets (Qt 4.x) for an example, it 
> requires a QGraphicsProxyWidget equivalent (QGPW was almost 2k LoC, a lot more 
> complex than the 103 line QWindowContainer WIP) and it requires a custom class 
> to expose widget properties to QML. So even a complex container element is not 
> enough, you also have to make every widget QML compatible (not actually that 
> hard, most of them use Q_PROPERTY already).

Not to mention the performance wreck it will turn into...

QGraphicsProxyWidget was horrible for performance if you had more than one or two. One reason for this is that the styles need to be rendered with raster (or possibly native) paint engines because of its ease of integration with native style APIs  and its superior quality compared to the OpenGL engine. This results in each widget having to be uploaded as a texture afterwards, so whenever something changes, we get rendering hickups. 

There are good usecases for such a class, embedding one or two toplevel widgets into an otherwise QML scene would probably be ok for performance. Embedding a proxied QPushButton for every button in the keyboard not so much...

I see a people having a certain technology, say charting, which is encapsulated in a QWidget, and it should be possible to integrate those technologies into QtQuick 2.0. Just make it really hard so it is not the obvious choice :)

cheers,
Gunnar