Background
QML is a relatively young language. The language itself and the tools around it are both evolving quite rapidly. For example,

• Qt 5.15 added macros to register C++ classes for QML at compile time, removing the need for using runtime registration or context properties (which are not visible to QML tools)
• Qt 6.2 added CMake API for creating QML modules, removing the need to manually write qmldir and *.qmltypes files (which are error prone)
• Qt 6.4 added support for lists of value types, so we can now convey intention more clearly (like using property list<int> numbers instead of property var numbers
• Qt 6.5 removed the need for custom import paths when defining custom QML modules, so can now remove boilerplate
• Qt 6.8 added a way to specify CMake targets as QML dependencies, which makes it easier to tell QML tools where to find dependencies and avoid warnings

However, a substantial amount of our examples, documentation, and code were written before these features became available. Consequently, they showcase old techniques (some which are now discouraged) and/or they light up with warnings when the user loads them:

Task

We must update them to use current best practices, so that:

• We take the lead in teaching best practices; we don't contribute to the inertial entrenchment of now-discouraged practices
• Our official examples look professional and trustworthy, free of warnings (QTBUG-110934)

Target Audience

The tasks under this Epic are for the benefit of two broad groups:

• Qt users (the primary target audience of our documentation and examples):
  • They rely on our examples and documentation to learn how to use Qt. If they see discouraged practices, then they will learn discouraged practices.
  • Examples/documentation that produce warnings causes user frustration and raises questions about the quality of our software.

• Those of us who design API for Qt users; those of us who review code/API/examples/documentation
  • Many people who write QML code are not experts in the cutting-edge developments of QML.
  • They might rely on internal, non-user-facing code as a template/reference for their work. Thus, such existing code can influence the design of new APIs/examples, and the outcomes of code reviews.

Thus, the tasks under this Epic cover examples, documentation, AND internal source code.