[Development] The place of QML

[Girish Ramakrishnan]

Hi Alan and Lars,

On Mon, Apr 23, 2012 at 10:59 AM, Alan Alpert <alan.alpert at nokia.com> wrote:
>> And as others already pointed out, we need to be careful as to what we
>> expose in C++. Any API we add comes at a large cost (that you probably do
>> not see) in terms of maintenance and limitations to what we can change
>> because of binary compatibility.
>
> I can see the non-zero value in exposing the Rectangle element. It's pretty much equivalent to QGraphicsRectItem then. I don't
> know about you, but I didn't find QGraphicsRectItem very useful at all. In a C++ graphics scene, it wasn't worth the bother to
> compose images out of multiple QGraphicsRectItems. That approach was cumbersome and inflexible compared to implementing your own
> QGraphicsItem and just painting a rectangle in paint(). Note that with QQuickPaintedItem, you can do the exact same thing with
> scenegraph today (well, on the day Qt5 is released ;) ) just take your QPainter* and go to town. Or use QQuickItem and paint it
> using scenegraph or GL directly, to truly get the sort of hardware acceleration and speed that requires custom C++ code. (NB:
> after writing your super-fast C++ native object you can then use QML to instantiate it and set initial properties, if that appeals
> to you.)
>

Rectangle is not the best example. Exposing any non-trivial QML
element through C++ code is a huge benefit. For example, it would have
been very useful to have the C++ of WebView public so that I can
expose new properties in QML - just see C++ QWebView and QML WebView
for the disparity. Currently, one has to fork the WebView private
implementation which is not nice at all. Another example - adding
wheel event support to our MouseArea.

I do think we should evaluate exposing the QML implementations to C++ for 5.1.

Girish