[Development] Is QML Item design deliberately hindering C++ interaction?

[Alan Alpert]

On Mon, Feb 2, 2015 at 3:43 PM, Alex Montgomery <apmontgomery at gmail.com> wrote:
> Is it a design goal of QML/Quick to discourage C++ interaction? I ask
> because every DevDays talk I attend includes some version of the
> phrase "any reasonably complex QML application will have C++ doing its
> back-end work", but yet I keep running into QML classes that hide
> important Qt C++ classes / data in their private implementation. I
> honestly am just trying to figure out if the philosophy of Qt Quick is
> to facilitate C++ interaction or discourage it.
>
> The strangest example of this push-pull is how Qt Quick handles drag
> and drop. If you derive from QQuickItem to handle drags, you get the
> classic Qt C++ API that uses classes like QDragEnterEvent and
> QDropEvent. Awesome. If you instead want to handle drops in QML, you
> get the Frankenstein class "DragEvent", known in C++ as
> QQuickDropEvent. This class is a strange mix of C++ only and C++
> hostile. If a drop has urls in its mime, you must use the "urllist"
> property, which is complete opaque/unusable to QML, so must be handled
> in C++ (See https://bugreports.qt.io/browse/QTBUG-42277 ). However, if
> you want to access the mime type directly and read custom mimetypes in
> C++, you can't, because QQuickDropEvent does not expose (but does keep
> internally) the actual QDropEvent that it encapsulates. So if you want
> to make custom mime data with bytearray-style blobs, you have to rely
> on its invokable function "getDataAsString" which may or may not
> mangle your binary data. I honestly can't tell. If I do a toLatin1()
> on it, will I get back the exact data in the mime type? I'm skeptical
> at best.
>
> TLDR: Are QML classes supposed to rely on C++ interactions or are they
> supposed to abstract them out of C++'s reach and force programmers to
> handle events in QML? I really want to know, because the answer right
> now seems to be "both" and it makes good architecture nearly
> impossible.

The good architecture, which is conveniently supposed to be enforced
by our inflexibility, is for QML to be the front-end/UI layer and C++
to be the back-end/business layer. So abstract data is supposed to be
easy to pass between the two, but UI classes (like QDragEnterEvent)
are not.

The custom Items case goes against this intended split. Custom
QQuickItems is not the C++ interaction that we commonly expect in QML
applications, and having to create your own custom QML items in C++
should be far, far rarer than creating your own custom QWidgets was.
If you are creating custom items you are going to hit some rough spots
due to the UI layer trying to stay contained from the C++ back-end. In
general we prefer to extend the functionality of the QtQuick elements
and the QML language to remove the need for custom QQuickItems.

That said, we still want custom items to be possible and not too hard
- the need is lessened compared to widgets but certainly not gone.
Binary data handling is something that we don't currently support in
QML well, and until we do custom QQuickItems seems like a reasonable
solution. This specific case is just a defect in our handling of drag
and drop (one of the more immature parts of QtQuick, I'll admit). It
should certainly be possible in theory to do custom binary mime data
from a custom QQuickItem, and it sounds like the current
implementation doesn't support that as well as it should.

--
Alan Alpert