Hi,
I don't think it's necessary to still flag the Android integration as TP
like it was in 6.7, we already iterated on the API to cover the initial
use case, and I think that one is covered by now in a way that we don't
expect to change.
I think there is a discussion to be had about how we can future proof it
to support non-graphical QML modules - and whether that makes sense in
the pure Android context. But I think that should be part of the normal
API review process that triggers after FF. One way forward there would
be to have a less strict coupling between the QtQmlComponent and the
QtQuickView via means of an interface; but let's have as a separate
discussion thread.
Concerns about where the code is currently located are also much less
pressing as with our C++ modules, given that we don't have to concern
ourselves with ABI and imports paths.
Kind regards,
Fabian
On 31.05.24 08:44, Ulf Hermann via Development wrote:
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
--
Fabian Kosmale
Manager R&D
The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosm...@qt.io
+49 1638686070
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
