[Development] The place of QML

Donald Carr sirspudd at gmail.com
Tue Apr 24 02:26:37 CEST 2012


Hey Girish,

On Mon, Apr 23, 2012 at 9:04 AM, Girish Ramakrishnan
<girish at forwardbias.in> wrote:
> 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.

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



More information about the Development mailing list