1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
|
// Copyright (C) 2020 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
/*!
\page qml-changes-qt6.html
\title Changes to Qt QML
\ingroup changes-qt-5-to-6
\brief Migrate Qt QML to Qt 6.
Qt 6 is a result of the conscious effort to make the framework more
efficient and easy to use.
We try to maintain binary and source compatibility for all the public
APIs in each release. But some changes were inevitable in an effort to
make Qt a better framework.
In this topic we summarize those changes in Qt QML, and provide
guidance to handle them.
\section1 QML language
\section2 URL resolution
In Qt 5, relative urls were often, albeit inconsistently, directly resolved, especially when
assigned to an url property. In Qt 6 this is no longer the case.
If you had a QML file stored under "/home/qml/example.qml", and "example.qml" contained
\code
property url imageFolder: "./images"
\endcode
then the url property would store the URL "/home/qml/images". This made it impossible to use
relative URLs in QML in this way, so in Qt 6, the URL stays relative, and only gets resolved
when this is required (e.g. when it is used as the source of an Image component).
If you depend on the old behavior, you can use \c Qt.resolvedUrl
For example, if you have code like
\code
property url imageFolder: "./images"
\endcode
you can rewrite it as
\code
property url imageFolder: Qt.resolvedUrl("./images")
\endcode
Qt.resolvedUrl can be used in both Qt 5 and 6.
\section2 Variant Properties
\c variant properties, which have been marked as obsolete since Qt 5, are now treated in exactly
the same way as \c var properties.
Code that relied on implicit string conversion triggered on assignment to variant properties
should be updated to explicitly create an object of the correct type.
For example, if you have code like
\code
property variant myColor: "red"
\endcode
you can rewrite it as
\code
property variant myColor: Qt.color("red")
\endcode
Implicit conversions were done for strings that could be parsed as
\list
\li color (use Qt.color instead),
\li date (use the Date object instead),
\li rect (use Qt.rect instead) and
\li size (use Qt.size instead)
\endlist
\c variant still remains a deprecated keyword in Qt 6, though new code is strongly encouraged to
use \c var properties instead.
\note If the type of the property is known not to change, use a property of the concrete type,
instead of a \c var property.
\note These conversions were also applied to \c QVariant properties of classes registered with
the engine. As with \c variant properties, code that relied on implicit string conversions need
to use the corresponding functions of the Qt object.
\section1 Source Incompatible API Changes
\section2 Changed API
\c QQmlListProperty's \c CountFunction and \c AtFunction have been changed to use \c qsizetype
instead of \c int to align with the corresponding changes in Qt's containers.
For example, if you have code like
\code
int myCountFunction(QQmlListProperty<MyType> *);
MyType *myAtFunction(QQmlListProperty<MyType> *, int);
QQmlListProperty<MyType> myReadOnlyList(containingObject, container, &myCountFunction,
&myAtFunction);
\endcode
you can rewrite it as
\code
qsizetype myCountFunction(QQmlListProperty<MyType> *);
MyType *myAtFunction(QQmlListProperty<MyType> *, qsizetype);
QQmlListProperty<MyType> myReadOnlyList(containingObject, container, &myCountFunction,
&myAtFunction);
\endcode
Code which needs to supports both Qt 5 and Qt 6 can either use a typedef which is \c int in Qt 5
and \c qsizetype in Qt 6, or use \c QList::size_type, which already is such a type alias.
\section2 Removed API
Various deprecated functions have been removed.
\list
\li The QQmlListProperty constructor taking a reference has been removed.
For example, if you have code like
\code
QQmlListProperty<QObject>(owner, owner->objectList);
\endcode
you can rewrite it as
\code
QQmlListProperty<QObject>(owner, &owner->objectList);
\endcode
\li The functions \c qmlDebug, \c qmlInfo, \c qmlWarning, \c qmlContext and \c qmlEngine used
to exist both in the global namespace (or Qt namespace in namespaced builds), and in the \c
QtQml namespace. These functions now exist only in the global namespace.
For example, if you have code like
\code
QQmlEngine *engine = QtQml::qmlEngine(qmlObject);
\endcode
you can rewrite it as
\code
QQmlEngine *engine = qmlEngine(qmlObject);
\endcode
\li The \c qmlRegisterType overload taking no arguments has been removed. Use
\c qmlRegisterAnonymousType instead, or switch to declarative type registration with
\c QML_ANONYMOUS.
For example, if you have code like
\code
class AnonymousType : public QObject {
// ...
};
qmlRegisterType<AnonymousType>();
\endcode
you can rewrite it as
\code
class AnonymousType : public QObject {
// ...
};
qmlRegisterAnonymousType<AnonymousType>("MyModule", 1);
\endcode
Or alternatively
\code
class AnonymousType : public QObject {
QML_ANONYMOUS
// ...
};
\endcode
\li The overloads of \c qmlRegisterExtendedType and \c qmlRegisterInterface
which take no version argument have been removed. Use the overloads providing a
version, or switch to declarative type registration with QML_EXTENDED
and QML_INTERFACE.
For example, if you have code like
\code
struct GreetInterface
{
virtual ~GreetInterface();
virtual void greet();
};
Q_DECLARE_INTERFACE(GreetInterface, "org.hi.GreetInterface")
qmlRegisterInterface<GreetInterface>("Greeter");
\endcode
you can rewrite it as
\code
struct GreetInterface
{
virtual ~GreetInterface();
virtual void greet();
};
Q_DECLARE_INTERFACE(GreetInterface, "org.hi.GreetInterface")
qmlRegisterInterface<GreetInterface>("Greeter", 1);
\endcode
Alternatively
\code
struct GreetInterface
{
QML_INTERFACE(Greeter)
virtual ~GreetInterface();
virtual void greet();
};
Q_DECLARE_INTERFACE(GreetInterface, "org.hi.GreetInterface")
\endcode
\note In new code, declarative type registration should be preferred.
\li The function \c QJSValue::engine has been removed. If access to the engine is required, a
reference to it must be stored instead.
\li \c qmlAttachedPropertiesObjectById and \c qmlAttachedPropertiesObject(int *, const QObject *,
const QMetaObject *, bool) have been removed. Use the
\c qmlAttachedPropertiesObject(QObject *, QQmlAttachedPropertiesFunc, bool) overload of
\c qmlAttachedPropertiesObject instead.
\li \c QJSEngine::installTranslatorFunctions has been removed. \c QJSEngine::installExtensions
is available as a replacement.
For example, if you have code like
\code
QJSEngine engine;
engine.installTranslatorFunctions();
\endcode
you can rewrite it as
\code
QJSEngine engine;
engine.installExtensions(QJSEngine::TranslationExtension);
\endcode
\endlist
*/
|
