Qt Contributor Summit 2019 - QtQml

From Qt Wiki
Revision as of 15:27, 22 November 2019 by EdwardWelbourne (talk | contribs) (Add to category QtCS2019)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Grouped properties

Grouped properties are incredibly buggy and basically unusable for anything but font and anchors right now. The language would be better off without the concept, allowing only the replacement of the full object (e.g., hypothetically, with inline components: "font: MyText.Font { bold: true }") rather than individual grouped properties. The semantics of such would be easier to understand and easier to implement, but people don't like this, of course.


Context properties

These are remarkably evil and actually unnecessary. You can readily replace them with singletons or object properties (possibly required ones) already in 5.15. We can deprecate context properties.



Once we get rid of unqualified lookups we don't need any QML versioning anymore. At least the minor version will become optional already in 5.15 for well-behaved QML documents. In QML 3 it won't be allowed.

Warnings / Transition to QML 3

We need a way of fine tuning the warnings. If you intend to port your program to QML 3 you want to see all deprecation warnings. If not, you want to suppress them all. If you want to stay with QML 2 but still fix some of the more glaring problems in your code, you may want to enable some warnings, but not others. We can have pragmas declaring what your code aims for in the QML files themselves and environment variables to switch warnings on or off. (In fact we want logging categories, but we didn't talk about that). We're not going to add replacement functionality (e.g. required properties) to 5.12 anymore. The base for porting to QML 3 has to be Qt 5.15.

Smart pointer support

We want QML to properly deal with smart pointers. For example, it should be possible to transfer ownership by moving a unique pointer.


Sequence types

We need a way to register your own container classes with the QML engine so that they behave the same way as certain auto-registered lists and vectors do. Also, people would like something akin to QQmlListProperty in qtbase. That is, a lightweight "model" that just grants access to some sequence data without providing storage for it.


Typed Model Data

We brainstormed a bit about how a model could declare its items' data type in QML, so that we could statically check model against delegate types. We will need this when compiling QML 3 to C++. We didn't come up with anything really great, though. This needs more work.