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 request involves extending existing functionality, the peanut gallery requests duplicating existing functionality so that it can accessed without them sullying their hands with something other than c++ or with _any_ runtime cost. Given the resourcing constraints that exist in any project, where do you want the effort expended? You know we refuse to be beholden to a C++ API for scenegraph, if people want a fixed C++ API they have to suggest/drive/implement one themselves which in turn relies on privates internals we reserve the right to stomp all over as need be. Anyone who wrote their app UI in QML1 just got a (free!) rocket inserted in their tail pipe and a license to pop a perpetual wheelie with Qt 5; contrast this to PSO's unspoken role in Qt 4 which was to frog march people through the Indiana Jonesque landscape of spikes, pits and reptiles that were the API calls required to get QGraphicsWebView occupying the whole screen and painting optimally. I am personally relieved our graphics team can perform major overhauls without cutting all of our customers/users in the process. True, when using QML 1 there was a necessary leap of faith that QML 2 was not going to be a complete rewrite, but we landed it and maintained a compelling degree of QML source compatibility while changing out the entire JS backend and rendering stack. (I did the sed work required to migrate a chunky codebase from a QML 1 to QML 2, has anyone here actually had a rough time of migrating from QtQuick 1.* to QtQuick 2.0) > 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? Cheers, Donald -- ------------------------------- °v° Donald Carr /(_)\ Vaguely Professional Penguin lover ^ ^ Cave canem, te necet lingendo Chasing my own tail; hate to see me leave, love to watch me go _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
