[Interest] Problems with qt_add_qml_module

[Nils Jeisecke]

Hi,

On Tue, Oct 24, 2023 at 4:35 PM Stefan Seefeld <stefan at seefeld.name> wrote:
> So it sounds like I still don't understand what `qt_add_qml_module` is doing.

AFAIK it builds a bunch of cmake custom commands that use moc for c++
and some other tooling for qml files to extract all the type
information. This then is the basis to the qmlsc, qmltc and plugin
code generators (qmlRegisterType etc.). All the generated stuff is
added to the backing target.

I've used these steps to modernize the code base of existing projects:

1. Port the Qml code to use proper modules. This can be partially
automated (https://github.com/njeisecke/qml-migration).

2. Move existing C++ code into proper qml modules, use QML_ELEMENT,
QML_SINGLETON etc., remove qmlRegisterType and fix the imports in the
qml files. This means quite some work and usually also comes with some
restructuring of the code base.

3. Replace all context properties by QML_SINGLETON classes providing
all previous context properties as typed class properties.

4. Fix all qmllint warnings. Your code will work but qmlsc won't
compile it to C++. There are still lots of places in Qml that make
typing and type checking hard (e.g. Loader.item can be anything) the
(undocumented) "as" operator is a great help here. Also inline
components are somewhat neglected as types by qmllint.

5. The hardest part: Refactor all Qml code to eliminate all
"unqualified access". There is a reason why this check is not enabled
in qmllint by default ;-) The scope lookup rules were a major design
fault in Qml, leading to uncheckable, uncompilable and hard to
maintain code.

It's quite an achievement to now have tooling in Qt 6.6 that allows
this iterative approach to overcome deficiencies inherently built into
the Qml DNA. Kudos to the Qml team.

You will finally be able to use qmllint for comprehensive type
checking of the qml/c++ code base which is a huge win for code quality
and maintenance.

Nils