Hi,
As noted before, we need to have a discussion on the new Android/Java
bindings and how they fit in with the QML language and various Qt
modules. See for example
https://codereview.qt-project.org/c/qt/qtdeclarative/+/563564 and
various follow-up changes.
I suggest we call the Android/Java bindings Tech Preview for now.
My main gripe is that the way it's written now, the language bindings,
the mapping of various model types, and the QtQuick support are all
added in one big package in src/quick. This limits what you can do with
e.g. the QtQmlComponent wrapper class. Ideally a QtQmlComponent should
be a generic building block for creating any QML component, independent
of any particular UI toolkit. There should also be a generic wrapper for
a QML engine that could instantiate QML components. This way we'd be
able to use the same building blocks for other Qt modules that expose
QML types, without depending on QtQuick.
For example: QtScxml has a QML integration that can be used without
QtQuick in C++. If you tie the Java-QML language bindings in with
QtQuick, you suddenly need to use QtQuick when employing the same
QtScxml/QML integration from Java. Such a thing will not sit well with
the maintainer of QtScxml.
I suggest to split the Java bindings into separate packages for each Qt
module, so that you can use them independently. The QtQml bindings
should provide common QML-related building blocks, such as a wrapper for
a QML engine and a wrapper for a QML component, that can be re-used in
other modules.
best regards,
Ulf
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
