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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
