Hi Alan and Lars, On Mon, Apr 23, 2012 at 10:59 AM, Alan Alpert <alan.alp...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
