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

[Alex Montgomery]

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.

Regards,
Alex