[Development] The place of QML

[Girish Ramakrishnan]

Hi Donald,

On Mon, Apr 23, 2012 at 5:26 PM, Donald Carr <sirspudd at gmail.com> wrote:
> 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

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