Hi Donald, On Mon, Apr 23, 2012 at 5:26 PM, Donald Carr <sirsp...@gmail.com> wrote: > Hey Girish, > > On Mon, Apr 23, 2012 at 9:04 AM, Girish Ramakrishnan > <gir...@forwardbias.in> wrote: >> 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. > > Rectangle is a perfect example for people who stand against QML on > principle alone. The idea of a QGraphicsView style API for scenegraph > is certainly the most vocal request from the peanut gallery. Your
I probably removed too much context in my reply. I was specifically replying to Lars comment below and alan's reply to that: "We are already exposing most of the the C++ APIs that make sense for application developers to use. Simply exposing the C++ interface of all QML elements won't buy you anything, as the most important feature of Qt Quick (bindings) still can't be handled that way. There's zero value in exposing the C++ class that implements the QML Rectangle element. There's nothing you can really do with it anyway. If you need to create your own QML elements in C++ we have QQuickItem and QQuickPaintedItem, which form a very good and solid basis." My reply was certainly not about adding C++ apis equivalents for scenegraph and C++ bindings apis and what not :) >> I do think we should evaluate exposing the QML implementations to C++ for >> 5.1. > > I think a better question would be; What existing evaluations exist? > And outside of the people seeking a contractual C++ API to scenegraph, > what evident extensibility/functionality issues exist in QML today? > My point above is an extensibility issue with our current QML offering. You cannot extend any existing QML element in C++. You have to start from scratch. We basically mark all existing QML items as 'final' for C++ use. Girish _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
