1 | /****************************************************************************
|
---|
2 | **
|
---|
3 | ** Copyright (C) 2011 Nokia Corporation and/or its subsidiary(-ies).
|
---|
4 | ** All rights reserved.
|
---|
5 | ** Contact: Nokia Corporation ([email protected])
|
---|
6 | **
|
---|
7 | ** This file is part of the documentation of the Qt Toolkit.
|
---|
8 | **
|
---|
9 | ** $QT_BEGIN_LICENSE:FDL$
|
---|
10 | ** Commercial Usage
|
---|
11 | ** Licensees holding valid Qt Commercial licenses may use this file in
|
---|
12 | ** accordance with the Qt Commercial License Agreement provided with the
|
---|
13 | ** Software or, alternatively, in accordance with the terms contained in a
|
---|
14 | ** written agreement between you and Nokia.
|
---|
15 | **
|
---|
16 | ** GNU Free Documentation License
|
---|
17 | ** Alternatively, this file may be used under the terms of the GNU Free
|
---|
18 | ** Documentation License version 1.3 as published by the Free Software
|
---|
19 | ** Foundation and appearing in the file included in the packaging of this
|
---|
20 | ** file.
|
---|
21 | **
|
---|
22 | ** If you have questions regarding the use of this file, please contact
|
---|
23 | ** Nokia at [email protected].
|
---|
24 | ** $QT_END_LICENSE$
|
---|
25 | **
|
---|
26 | ****************************************************************************/
|
---|
27 |
|
---|
28 | /*!
|
---|
29 | \page qtbinding.html
|
---|
30 | \target qtbinding
|
---|
31 | \title Using QML in C++ Applications
|
---|
32 |
|
---|
33 | QML is designed to be easily extensible from C++. The classes in the
|
---|
34 | Qt Declarative module allow QML components to be loaded and manipulated from C++, and through
|
---|
35 | Qt's \l{The Meta-Object System}{meta-object system}, QML and C++ objects can easily
|
---|
36 | communicate through Qt signals and slots. In addition, QML plugins can be written to create
|
---|
37 | reusable QML components for distribution.
|
---|
38 |
|
---|
39 | You may want to mix QML and C++ for a number of reasons. For example:
|
---|
40 |
|
---|
41 | \list
|
---|
42 | \o To use functionality defined in a C++ source (for example, when using a C++ Qt-based data model, or
|
---|
43 | calling functions in a third-party C++ library)
|
---|
44 | \o To access functionality in the Qt Declarative module (for example, to dynamically generate
|
---|
45 | images using QDeclarativeImageProvider)
|
---|
46 | \o To write your own QML elements (whether for your applications, or for distribution to others)
|
---|
47 | \endlist
|
---|
48 |
|
---|
49 | To use the Qt Declarative module, you must include and link to the module appropriately, as shown on
|
---|
50 | the \l {QtDeclarative}{module index page}. The \l {Qt Declarative UI Runtime} documentation
|
---|
51 | shows how to build a basic C++ application that uses this module.
|
---|
52 |
|
---|
53 |
|
---|
54 | \section1 Core module classes
|
---|
55 |
|
---|
56 | The Qt Declarative module provides a set of C++ APIs for extending your QML applications from C++ and
|
---|
57 | embedding QML into C++ applications. There are several core classes in the Qt Declarative module
|
---|
58 | that provide the essential capabilities for doing this. These are:
|
---|
59 |
|
---|
60 | \list
|
---|
61 | \o QDeclarativeEngine: A QML engine provides the environment for executing QML code. Every
|
---|
62 | application requires at least one engine instance.
|
---|
63 | \o QDeclarativeComponent: A component encapsulates a \l{QML Documents}{QML document}.
|
---|
64 | \o QDeclarativeContext: A context allows an application to expose data to the QML components
|
---|
65 | created by an engine.
|
---|
66 | \endlist
|
---|
67 |
|
---|
68 | A QDeclarativeEngine allows the configuration of global settings that apply to all of its QML
|
---|
69 | component instances: for example, the QNetworkAccessManager to be used for network communications,
|
---|
70 | and the file path to be used for persistent storage.
|
---|
71 |
|
---|
72 | QDeclarativeComponent is used to load QML documents. Each QDeclarativeComponent instance represents
|
---|
73 | a single document. A component can be created from the URL or file path of a QML document, or the raw
|
---|
74 | QML code of the document. Component instances are instatiated through the
|
---|
75 | QDeclarativeComponent::create() method, like this:
|
---|
76 |
|
---|
77 | \code
|
---|
78 | QDeclarativeEngine engine;
|
---|
79 | QDeclarativeComponent component(&engine, QUrl::fromLocalFile("MyRectangle.qml"));
|
---|
80 | QObject *rectangleInstance = component.create();
|
---|
81 |
|
---|
82 | // ...
|
---|
83 | delete rectangleInstance;
|
---|
84 | \endcode
|
---|
85 |
|
---|
86 | QML documents can also be loaded using QDeclarativeView. This class provides a convenient
|
---|
87 | QWidget-based view for embedding QML components into QGraphicsView-based applications. (For other
|
---|
88 | methods of integrating QML into QWidget-based applications, see \l {Integrating QML with existing Qt
|
---|
89 | UI code}.)
|
---|
90 |
|
---|
91 |
|
---|
92 | \section1 Approaches to using QML with C++
|
---|
93 |
|
---|
94 | There are a number of ways to extend your QML application through C++. For example, you could:
|
---|
95 |
|
---|
96 | \list
|
---|
97 | \o Load a QML component and manipulate it (or its children) from C++
|
---|
98 | \o Embed a C++ object and its properties directly into a QML component (for example, to make a
|
---|
99 | particular C++ object callable from QML, or to replace a dummy list model with a real data set)
|
---|
100 | \o Define new QML elements (through QObject-based C++ classes) and create them directly from your
|
---|
101 | QML code
|
---|
102 | \endlist
|
---|
103 |
|
---|
104 | These methods are shown below. Naturally these approaches are not exclusive; you can mix any of
|
---|
105 | these methods throughout your application as appropriate.
|
---|
106 |
|
---|
107 |
|
---|
108 | \section2 Loading QML components from C++
|
---|
109 |
|
---|
110 | A QML document can be loaded with QDeclarativeComponent or QDeclarativeView. QDeclarativeComponent
|
---|
111 | loads a QML component as a C++ object; QDeclarativeView also does this,
|
---|
112 | but additionally loads the QML component directly into a QGraphicsView. It is convenient for loading
|
---|
113 | a displayable QML component into a QWidget-based application.
|
---|
114 |
|
---|
115 | For example, suppose there is a \c MyItem.qml file that looks like this:
|
---|
116 |
|
---|
117 | \snippet doc/src/snippets/declarative/qtbinding/loading/MyItem.qml start
|
---|
118 | \snippet doc/src/snippets/declarative/qtbinding/loading/MyItem.qml end
|
---|
119 |
|
---|
120 | This QML document can be loaded with QDeclarativeComponent or QDeclarativeView with the following
|
---|
121 | C++ code. Using a QDeclarativeComponent requires calling QDeclarativeComponent::create() to create
|
---|
122 | a new instance of the component, while a QDeclarativeView automatically creates an instance of the
|
---|
123 | component, which is accessible via QDeclarativeView::rootObject():
|
---|
124 |
|
---|
125 | \table
|
---|
126 | \row
|
---|
127 | \o
|
---|
128 | \snippet doc/src/snippets/declarative/qtbinding/loading/main.cpp QDeclarativeComponent-a
|
---|
129 | \dots 0
|
---|
130 | \snippet doc/src/snippets/declarative/qtbinding/loading/main.cpp QDeclarativeComponent-b
|
---|
131 | \o
|
---|
132 | \snippet doc/src/snippets/declarative/qtbinding/loading/main.cpp QDeclarativeView
|
---|
133 | \endtable
|
---|
134 |
|
---|
135 | This \c object is the instance of the \c MyItem.qml component that has been created. You can now
|
---|
136 | modify the item's properties using QObject::setProperty() or QDeclarativeProperty:
|
---|
137 |
|
---|
138 | \snippet doc/src/snippets/declarative/qtbinding/loading/main.cpp properties
|
---|
139 |
|
---|
140 | Alternatively, you can cast the object to its actual type and call functions with compile-time
|
---|
141 | safety. In this case the base object of \c MyItem.qml is an \l Item, which is defined by the
|
---|
142 | QDeclarativeItem class:
|
---|
143 |
|
---|
144 | \snippet doc/src/snippets/declarative/qtbinding/loading/main.cpp cast
|
---|
145 |
|
---|
146 | You can also connect to any signals or call functions defined in the component using
|
---|
147 | QMetaObject::invokeMethod() and QObject::connect(). See \l {Exchanging data between QML and C++}
|
---|
148 | below for further details.
|
---|
149 |
|
---|
150 | \section3 Locating child objects
|
---|
151 |
|
---|
152 | QML components are essentially object trees with children that have siblings and their own children.
|
---|
153 | Child objects of QML components can be located using the QObject::objectName property with
|
---|
154 | QObject::findChild(). For example, if the root item in \c MyItem.qml had a child \l Rectangle item:
|
---|
155 |
|
---|
156 | \snippet doc/src/snippets/declarative/qtbinding/loading/MyItem.qml start
|
---|
157 | \codeline
|
---|
158 | \snippet doc/src/snippets/declarative/qtbinding/loading/MyItem.qml child
|
---|
159 | \snippet doc/src/snippets/declarative/qtbinding/loading/MyItem.qml end
|
---|
160 |
|
---|
161 | The child could be located like this:
|
---|
162 |
|
---|
163 | \snippet doc/src/snippets/declarative/qtbinding/loading/main.cpp findChild
|
---|
164 |
|
---|
165 | If \c objectName is used inside a delegate of a ListView, \l Repeater or some other
|
---|
166 | element that creates multiple instances of its delegates, there will be multiple children with
|
---|
167 | the same \c objectName. In this case, QObject::findChildren() can be used to find all children
|
---|
168 | with a matching \c objectName.
|
---|
169 |
|
---|
170 | \warning While it is possible to use C++ to access and manipulate QML objects deep into the
|
---|
171 | object tree, we recommend that you do not take this approach outside of application
|
---|
172 | testing and prototyping. One strength of QML and C++ integration is the ability to implement the
|
---|
173 | QML user interface separately from the C++ logic and dataset backend, and this strategy breaks if the
|
---|
174 | C++ side reaches deep into the QML components to manipulate them directly. This would make it difficult
|
---|
175 | to, for example, swap a QML view component for another view, if the new component was missing a
|
---|
176 | required \c objectName. It is better for the C++ implementation to know as little as possible about
|
---|
177 | the QML user interface implementation and the composition of the QML object tree.
|
---|
178 |
|
---|
179 |
|
---|
180 | \section2 Embedding C++ objects into QML components
|
---|
181 |
|
---|
182 | When loading a QML scene into a C++ application, it can be useful to directly embed C++ data into
|
---|
183 | the QML object. QDeclarativeContext enables this by exposing data to the context of a QML
|
---|
184 | component, allowing data to be injected from C++ into QML.
|
---|
185 |
|
---|
186 | For example, here is a QML item that refers to a \c currentDateTime value that does not exist in
|
---|
187 | the current scope:
|
---|
188 |
|
---|
189 | \snippet doc/src/snippets/declarative/qtbinding/context/MyItem.qml 0
|
---|
190 |
|
---|
191 | This \c currentDateTime value can be set directly by the C++ application that loads the QML
|
---|
192 | component, using QDeclarativeContext::setContextProperty():
|
---|
193 |
|
---|
194 | \snippet doc/src/snippets/declarative/qtbinding/context/main.cpp 0
|
---|
195 |
|
---|
196 | Context properties can hold either QVariant or QObject* values. This means custom C++ objects can
|
---|
197 | also be injected using this approach, and these objects can be modified and read directly in QML.
|
---|
198 | Here, we modify the above example to embed a QObject instance instead of a QDateTime value, and the QML code
|
---|
199 | invokes a method on the object instance:
|
---|
200 |
|
---|
201 | \table
|
---|
202 | \row
|
---|
203 | \o
|
---|
204 | \snippet doc/src/snippets/declarative/qtbinding/context-advanced/applicationdata.h 0
|
---|
205 | \codeline
|
---|
206 | \snippet doc/src/snippets/declarative/qtbinding/context-advanced/main.cpp 0
|
---|
207 | \o
|
---|
208 | \snippet doc/src/snippets/declarative/qtbinding/context-advanced/MyItem.qml 0
|
---|
209 | \endtable
|
---|
210 |
|
---|
211 | (Note that date/time values returned from C++ to QML can be formatted through
|
---|
212 | \l{QML:Qt::formatDateTime}{Qt.formatDateTime()} and associated functions.)
|
---|
213 |
|
---|
214 | If the QML item needs to receive signals from the context property, it can connect to them using the
|
---|
215 | \l Connections element. For example, if \c ApplicationData has a signal named \c
|
---|
216 | dataChanged(), this signal can be connected to using an \c onDataChanged handler within
|
---|
217 | a \l Connections object:
|
---|
218 |
|
---|
219 | \snippet doc/src/snippets/declarative/qtbinding/context-advanced/connections.qml 0
|
---|
220 |
|
---|
221 | Context properties can be useful for using C++ based data models in a QML view. See the
|
---|
222 | \l {declarative/modelviews/stringlistmodel}{String ListModel},
|
---|
223 | \l {declarative/modelviews/objectlistmodel}{Object ListModel} and
|
---|
224 | \l {declarative/modelviews/abstractitemmodel}{AbstractItemModel} models for
|
---|
225 | respective examples on using QStringListModel, QObjectList-based models and QAbstractItemModel
|
---|
226 | in QML views.
|
---|
227 |
|
---|
228 | Also see the QDeclarativeContext documentation for more information.
|
---|
229 |
|
---|
230 |
|
---|
231 | \section2 Defining new QML elements
|
---|
232 |
|
---|
233 | While new QML elements can be \l {Defining New Components}{defined in QML}, they can also be
|
---|
234 | defined by C++ classes; in fact, many of the core \l {QML Elements} are implemented through
|
---|
235 | C++ classes. When you create a QML object using one of these elements, you are simply creating an
|
---|
236 | instance of a QObject-based C++ class and setting its properties.
|
---|
237 |
|
---|
238 | For example, here is an \c ImageViewer class with an \c image URL property:
|
---|
239 |
|
---|
240 | \snippet doc/src/snippets/declarative/qtbinding/newelements/imageviewer.h 0
|
---|
241 |
|
---|
242 | Aside from the fact that it inherits QDeclarativeItem, this is an ordinary class that could
|
---|
243 | exist outside of QML. However, once it is registered with the QML engine using qmlRegisterType():
|
---|
244 |
|
---|
245 | \snippet doc/src/snippets/declarative/qtbinding/newelements/main.cpp register
|
---|
246 |
|
---|
247 | Then, any QML code loaded by your C++ application or \l{QDeclarativeExtensionPlugin}{plugin} can create and manipulate
|
---|
248 | \c ImageViewer objects:
|
---|
249 |
|
---|
250 | \snippet doc/src/snippets/declarative/qtbinding/newelements/standalone.qml 0
|
---|
251 |
|
---|
252 | Note that custom C++ types do not have to inherit from QDeclarativeItem; this is only necessary if it is
|
---|
253 | a displayable item. If the item is not displayable, it can simply inherit from QObject.
|
---|
254 |
|
---|
255 | For more information on defining new QML elements, see the \l {Tutorial: Writing QML extensions with C++}
|
---|
256 | {Writing QML extensions with C++} tutorial and the \l {Extending QML in C++} reference
|
---|
257 | documentation.
|
---|
258 |
|
---|
259 |
|
---|
260 |
|
---|
261 | \section1 Exchanging data between QML and C++
|
---|
262 |
|
---|
263 | QML and C++ objects can communicate with one another through signals, slots and property
|
---|
264 | modifications. For a C++ object, any data that is exposed to Qt's \l{The Meta-Object System}{Meta-Object System}
|
---|
265 | - that is, properties, signals, slots and Q_INVOKABLE methods - become available to QML. On
|
---|
266 | the QML side, all QML object data is automatically made available to the meta-object system and can
|
---|
267 | be accessed from C++.
|
---|
268 |
|
---|
269 |
|
---|
270 | \section2 Calling functions
|
---|
271 |
|
---|
272 | QML functions can be called from C++ and vice-versa.
|
---|
273 |
|
---|
274 | All QML functions are exposed to the meta-object system and can be called using
|
---|
275 | QMetaObject::invokeMethod(). Here is a C++ application that uses this to call a QML function:
|
---|
276 |
|
---|
277 | \table
|
---|
278 | \row
|
---|
279 | \o \snippet doc/src/snippets/declarative/qtbinding/functions-qml/MyItem.qml 0
|
---|
280 | \o \snippet doc/src/snippets/declarative/qtbinding/functions-qml/main.cpp 0
|
---|
281 | \endtable
|
---|
282 |
|
---|
283 | Notice the Q_RETURN_ARG() and Q_ARG() arguments for QMetaObject::invokeMethod() must be specified as
|
---|
284 | QVariant types, as this is the generic data type used for QML functions and return values.
|
---|
285 |
|
---|
286 | To call a C++ function from QML, the function must be either a Qt slot, or a function marked with
|
---|
287 | the Q_INVOKABLE macro, to be available to QML. In the following example, the QML code invokes
|
---|
288 | methods on the \c myObject object, which has been set using QDeclarativeContext::setContextProperty():
|
---|
289 |
|
---|
290 | \table
|
---|
291 | \row
|
---|
292 | \o
|
---|
293 | \snippet doc/src/snippets/declarative/qtbinding/functions-cpp/MyItem.qml 0
|
---|
294 | \o
|
---|
295 | \snippet doc/src/snippets/declarative/qtbinding/functions-cpp/myclass.h 0
|
---|
296 | \codeline
|
---|
297 | \snippet doc/src/snippets/declarative/qtbinding/functions-cpp/main.cpp 0
|
---|
298 | \endtable
|
---|
299 |
|
---|
300 | QML supports the calling of overloaded C++ functions. If there are multiple C++ functions with the
|
---|
301 | same name but different arguments, the correct function will be called according to the number and
|
---|
302 | the types of arguments that are provided.
|
---|
303 |
|
---|
304 |
|
---|
305 | \section2 Receiving signals
|
---|
306 |
|
---|
307 | All QML signals are automatically available to C++, and can be connected to using QObject::connect()
|
---|
308 | like any ordinary Qt C++ signal. In return, any C++ signal can be received by a QML object using
|
---|
309 | \l {Signal Handlers}{signal handlers}.
|
---|
310 |
|
---|
311 | Here is a QML component with a signal named \c qmlSignal. This signal is connected to a C++ object's
|
---|
312 | slot using QObject::connect(), so that the \c cppSlot() method is called whenever the \c qmlSignal
|
---|
313 | is emitted:
|
---|
314 |
|
---|
315 | \table
|
---|
316 | \row
|
---|
317 | \o
|
---|
318 | \snippet doc/src/snippets/declarative/qtbinding/signals-qml/MyItem.qml 0
|
---|
319 | \o
|
---|
320 | \snippet doc/src/snippets/declarative/qtbinding/signals-qml/myclass.h 0
|
---|
321 | \codeline
|
---|
322 | \snippet doc/src/snippets/declarative/qtbinding/signals-qml/main.cpp 0
|
---|
323 | \endtable
|
---|
324 |
|
---|
325 | To connect to Qt C++ signals from within QML, use a signal handler with the \c on<SignalName> syntax.
|
---|
326 | If the C++ object is directly creatable from within QML (see \l {Defining new QML elements} above)
|
---|
327 | then the signal handler can be defined within the object declaration. In the following example, the
|
---|
328 | QML code creates a \c ImageViewer object, and the \c imageChanged and \c loadingError signals of the
|
---|
329 | C++ object are connected to through \c onImagedChanged and \c onLoadingError signal handlers in QML:
|
---|
330 |
|
---|
331 | \table
|
---|
332 | \row
|
---|
333 | \o
|
---|
334 |
|
---|
335 | \snippet doc/src/snippets/declarative/qtbinding/signals-cpp/imageviewer.h start
|
---|
336 | \dots 4
|
---|
337 | \snippet doc/src/snippets/declarative/qtbinding/signals-cpp/imageviewer.h end
|
---|
338 |
|
---|
339 | \o
|
---|
340 | \snippet doc/src/snippets/declarative/qtbinding/signals-cpp/standalone.qml 0
|
---|
341 | \endtable
|
---|
342 |
|
---|
343 | (Note that if a signal has been declared as the NOTIFY signal for a property, QML allows it to be
|
---|
344 | received with an \c on<Property>Changed handler even if the signal's name does not follow the \c
|
---|
345 | <Property>Changed naming convention. In the above example, if the "imageChanged" signal was named
|
---|
346 | "imageModified" instead, the \c onImageChanged signal handler would still be called.)
|
---|
347 |
|
---|
348 | If, however, the object with the signal is not created from within the QML code, and the QML item only has a
|
---|
349 | reference to the created object - for example, if the object was set using
|
---|
350 | QDeclarativeContext::setContextProperty() - then the \l Connections element can be used
|
---|
351 | instead to create the signal handler:
|
---|
352 |
|
---|
353 | \table
|
---|
354 | \row
|
---|
355 | \o \snippet doc/src/snippets/declarative/qtbinding/signals-cpp/main.cpp connections
|
---|
356 | \o \snippet doc/src/snippets/declarative/qtbinding/signals-cpp/MyItem.qml 0
|
---|
357 | \endtable
|
---|
358 |
|
---|
359 |
|
---|
360 | \section2 Modifying properties
|
---|
361 |
|
---|
362 | Any properties declared in a QML object are automatically accessible from C++. Given a QML item
|
---|
363 | like this:
|
---|
364 |
|
---|
365 | \snippet doc/src/snippets/declarative/qtbinding/properties-qml/MyItem.qml 0
|
---|
366 |
|
---|
367 | The value of the \c someNumber property can be set and read using QDeclarativeProperty, or
|
---|
368 | QObject::setProperty() and QObject::property():
|
---|
369 |
|
---|
370 | \snippet doc/src/snippets/declarative/qtbinding/properties-qml/main.cpp 0
|
---|
371 |
|
---|
372 | You should always use QObject::setProperty(), QDeclarativeProperty or QMetaProperty::write() to
|
---|
373 | change a QML property value, to ensure the QML engine is made aware of the property change. For example,
|
---|
374 | say you have a custom element \c PushButton with a \c buttonText property that internally reflects
|
---|
375 | the value of a \c m_buttonText member variable. Modifying the member variable directly like this is
|
---|
376 | not a good idea:
|
---|
377 |
|
---|
378 | \badcode
|
---|
379 | // BAD!
|
---|
380 | QDeclarativeComponent component(engine, "MyButton.qml");
|
---|
381 | PushButton *button = qobject_cast<PushButton*>(component.create());
|
---|
382 | button->m_buttonText = "Click me";
|
---|
383 | \endcode
|
---|
384 |
|
---|
385 | Since the value is changed directly, this bypasses Qt's \l{The Meta-Object System}{meta-object system}
|
---|
386 | and the QML engine is not made aware of the property change. This means property bindings to
|
---|
387 | \c buttonText would not be updated, and any \c onButtonTextChanged handlers would not be called.
|
---|
388 |
|
---|
389 |
|
---|
390 | \target properties-cpp
|
---|
391 |
|
---|
392 | Any \l {The Property System}{Qt properties} - that is, those declared with the Q_PROPERTY()
|
---|
393 | macro - are accessible from QML. Here is a modified version of the \l {Embedding C++ objects into
|
---|
394 | QML components}{earlier example} on this page; here, the \c ApplicationData class has a \c backgroundColor
|
---|
395 | property. This property can be written to and read from QML:
|
---|
396 |
|
---|
397 | \table
|
---|
398 | \row
|
---|
399 | \o \snippet doc/src/snippets/declarative/qtbinding/properties-cpp/applicationdata.h 0
|
---|
400 | \o \snippet doc/src/snippets/declarative/qtbinding/properties-cpp/MyItem.qml 0
|
---|
401 | \endtable
|
---|
402 |
|
---|
403 | Notice the \c backgroundColorChanged signal is declared as the NOTIFY signal for the
|
---|
404 | \c backgroundColor property. If a Qt property does not have an associated NOTIFY signal,
|
---|
405 | the property cannot be used for \l {Property Binding} in QML, as the QML engine would not be
|
---|
406 | notified when the value changes. If you are using custom types in QML, make sure their
|
---|
407 | properties have NOTIFY signals so that they can be used in property bindings.
|
---|
408 |
|
---|
409 | See \l {Tutorial: Writing QML extensions with C++} for further details and examples
|
---|
410 | on using Qt properties with QML.
|
---|
411 |
|
---|
412 |
|
---|
413 | \section1 Supported data types
|
---|
414 |
|
---|
415 | Any C++ data that is used from QML - whether as custom properties, or parameters for signals or
|
---|
416 | functions - must be of a type that is recognizable by QML.
|
---|
417 |
|
---|
418 | By default, QML recognizes the following data types:
|
---|
419 |
|
---|
420 | \list
|
---|
421 | \o bool
|
---|
422 | \o unsigned int, int
|
---|
423 | \o float, double, qreal
|
---|
424 | \o QString
|
---|
425 | \o QUrl
|
---|
426 | \o QColor
|
---|
427 | \o QDate, QTime, QDateTime
|
---|
428 | \o QPoint, QPointF
|
---|
429 | \o QSize, QSizeF
|
---|
430 | \o QRect, QRectF
|
---|
431 | \o QVariant
|
---|
432 | \o QVariantList, QVariantMap
|
---|
433 | \o QObject*
|
---|
434 | \o Enumerations declared with Q_ENUMS()
|
---|
435 | \endlist
|
---|
436 |
|
---|
437 | To allow a custom C++ type to be created or used in QML, the C++ class must be registered as a QML
|
---|
438 | type using qmlRegisterType(), as shown in the \l {Defining new QML elements} section above.
|
---|
439 |
|
---|
440 |
|
---|
441 | \section2 JavaScript arrays and objects
|
---|
442 |
|
---|
443 | There is built-in support for automatic type conversion between QVariantList and JavaScript
|
---|
444 | arrays, and QVariantMap and JavaScript objects.
|
---|
445 |
|
---|
446 | For example, the function defined in QML below left expects two arguments, an array and an object, and prints
|
---|
447 | their contents using the standard JavaScript syntax for array and object item access. The C++ code
|
---|
448 | below right calls this function, passing a QVariantList and a QVariantMap, which are automatically
|
---|
449 | converted to JavaScript array and object values, repectively:
|
---|
450 |
|
---|
451 | \table
|
---|
452 | \row
|
---|
453 | \o \snippet doc/src/snippets/declarative/qtbinding/variantlistmap/MyItem.qml 0
|
---|
454 | \o \snippet doc/src/snippets/declarative/qtbinding/variantlistmap/main.cpp 0
|
---|
455 | \endtable
|
---|
456 |
|
---|
457 | This produces output like:
|
---|
458 |
|
---|
459 | \code
|
---|
460 | Array item: 10
|
---|
461 | Array item: #00ff00
|
---|
462 | Array item: bottles
|
---|
463 | Object item: language = QML
|
---|
464 | Object item: released = Tue Sep 21 2010 00:00:00 GMT+1000 (EST)
|
---|
465 | \endcode
|
---|
466 |
|
---|
467 | Similarly, if a C++ type uses a QVariantList or QVariantMap type for a property or method
|
---|
468 | parameter, the value can be created as a JavaScript array or object in the QML
|
---|
469 | side, and is automatically converted to a QVariantList or QVariantMap when it is passed to C++.
|
---|
470 |
|
---|
471 |
|
---|
472 | \section2 Using enumerations of a custom type
|
---|
473 |
|
---|
474 | To use an enumeration from a custom C++ component, the enumeration must be declared with Q_ENUMS() to
|
---|
475 | register it with Qt's meta object system. For example, the following C++ type has a \c Status enum:
|
---|
476 |
|
---|
477 | \snippet doc/src/snippets/declarative/qtbinding/enums/imageviewer.h start
|
---|
478 | \snippet doc/src/snippets/declarative/qtbinding/enums/imageviewer.h end
|
---|
479 |
|
---|
480 | Providing the \c ImageViewer class has been registered using qmlRegisterType(), its \c Status enum can
|
---|
481 | now be used from QML:
|
---|
482 |
|
---|
483 | \snippet doc/src/snippets/declarative/qtbinding/enums/standalone.qml 0
|
---|
484 |
|
---|
485 | The C++ type must be registered with QML to use its enums. If your C++ type is not instantiable, it
|
---|
486 | can be registered using qmlRegisterUncreatableType(). To be accessible from QML, the names of enum values
|
---|
487 | must begin with a capital letter.
|
---|
488 |
|
---|
489 | See the \l {Tutorial: Writing QML extensions with C++}{Writing QML extensions with C++} tutorial and
|
---|
490 | the \l {Extending QML in C++} reference documentation for more information.
|
---|
491 |
|
---|
492 |
|
---|
493 | \section2 Automatic type conversion from strings
|
---|
494 |
|
---|
495 | As a convenience, some basic types can be specified in QML using format strings to make it easier to
|
---|
496 | pass simple values from QML to C++.
|
---|
497 |
|
---|
498 | \table
|
---|
499 | \header
|
---|
500 | \o Type
|
---|
501 | \o String format
|
---|
502 | \o Example
|
---|
503 | \row
|
---|
504 | \o QColor
|
---|
505 | \o Color name, "#RRGGBB", "#RRGGBBAA"
|
---|
506 | \o "red", "#ff0000", "#ff000000"
|
---|
507 | \row
|
---|
508 | \o QDate
|
---|
509 | \o "YYYY-MM-DD"
|
---|
510 | \o "2010-05-31"
|
---|
511 | \row
|
---|
512 | \o QPoint
|
---|
513 | \o "x,y"
|
---|
514 | \o "10,20"
|
---|
515 | \row
|
---|
516 | \o QRect
|
---|
517 | \o "x,y,WidthxHeight"
|
---|
518 | \o "50,50,100x100"
|
---|
519 | \row
|
---|
520 | \o QSize
|
---|
521 | \o "WidthxHeight"
|
---|
522 | \o "100x200"
|
---|
523 | \row
|
---|
524 | \o QTime
|
---|
525 | \o "hh:mm:ss"
|
---|
526 | \o "14:22:55"
|
---|
527 | \row
|
---|
528 | \o QUrl
|
---|
529 | \o URL string
|
---|
530 | \o "http://www.example.com"
|
---|
531 | \row
|
---|
532 | \o QVector3D
|
---|
533 | \o "x,y,z"
|
---|
534 | \o "0,1,0"
|
---|
535 | \row
|
---|
536 | \o Enumeration value
|
---|
537 | \o Enum value name
|
---|
538 | \o "AlignRight"
|
---|
539 | \endtable
|
---|
540 |
|
---|
541 | (More details on these string formats and types can be found in the
|
---|
542 | \l {QML Basic Types}{basic type documentation}.)
|
---|
543 |
|
---|
544 | These string formats can be used to set QML \c property values and pass arguments to C++
|
---|
545 | functions. This is demonstrated by various examples on this page; in the above
|
---|
546 | \l{#properties-cpp}{Qt properties example}, the \c ApplicationData class has a \c backgroundColor
|
---|
547 | property of a QColor type, which is set from the QML code with the string "red" rather rather
|
---|
548 | than an actual QColor object.
|
---|
549 |
|
---|
550 | If it is preferred to pass an explicitly-typed value rather than a string, the global
|
---|
551 | \l{QmlGlobalQtObject}{Qt object} provides convenience functions for creating some of the object
|
---|
552 | types listed above. For example, \l{QML:Qt::rgba()}{Qt.rgba()} creates a QColor value from four
|
---|
553 | RGBA values. The QColor returned from this function could be used instead of a string to set
|
---|
554 | a QColor-type property or to call a C++ function that requires a QColor parameter.
|
---|
555 |
|
---|
556 |
|
---|
557 | \section1 Writing QML plugins
|
---|
558 |
|
---|
559 | The Qt Declarative module includes the QDeclarativeExtensionPlugin class, which is an abstract
|
---|
560 | class for writing QML plugins. This allows QML extension types to be dynamically loaded into
|
---|
561 | QML applications.
|
---|
562 |
|
---|
563 | See the QDeclarativeExtensionPlugin documentation and \l {How to Create Qt Plugins} for more
|
---|
564 | details.
|
---|
565 |
|
---|
566 |
|
---|
567 | \section1 Managing resource files with the Qt resource system
|
---|
568 |
|
---|
569 | The \l {The Qt Resource System}{Qt resource system} allows resource files to be stored as
|
---|
570 | binary files in an application executable. This can be useful when building a mixed
|
---|
571 | QML/C++ application as it enables QML files (as well as other resources such as images
|
---|
572 | and sound files) to be referred to through the resource system URI scheme rather than
|
---|
573 | relative or absolute paths to filesystem resources. Note, however, that if you use the resource
|
---|
574 | system, the application executable must be re-compiled whenever a QML source file is changed
|
---|
575 | in order to update the resources in the package.
|
---|
576 |
|
---|
577 | To use the resource system in a mixed QML/C++ application:
|
---|
578 |
|
---|
579 | \list
|
---|
580 | \o Create a \c .qrc \l {The Qt Resource System}{resource collection file} that lists resource
|
---|
581 | files in XML format
|
---|
582 | \o From C++, load the main QML file as a resource using the \c :/ prefix or as a URL with the
|
---|
583 | \c qrc scheme
|
---|
584 | \endlist
|
---|
585 |
|
---|
586 | Once this is done, all files specified by relative paths in QML will be loaded from
|
---|
587 | the resource system instead. Use of the resource system is completely transparent to
|
---|
588 | the QML layer; this means all QML code should refer to resource files using relative
|
---|
589 | paths and should \e not use the \c qrc scheme. This scheme should only be used from
|
---|
590 | C++ code for referring to resource files.
|
---|
591 |
|
---|
592 | Here is a application packaged using the \l {The Qt Resource System}{Qt resource system}.
|
---|
593 | The directory structure looks like this:
|
---|
594 |
|
---|
595 | \code
|
---|
596 | project
|
---|
597 | |- example.qrc
|
---|
598 | |- main.qml
|
---|
599 | |- images
|
---|
600 | |- background.png
|
---|
601 | |- main.cpp
|
---|
602 | |- project.pro
|
---|
603 | \endcode
|
---|
604 |
|
---|
605 | The \c main.qml and \c background.png files will be packaged as resource files. This is
|
---|
606 | done in the \c example.qrc resource collection file:
|
---|
607 |
|
---|
608 | \quotefile doc/src/snippets/declarative/qtbinding/resources/example.qrc
|
---|
609 |
|
---|
610 | Since \c background.png is a resource file, \c main.qml can refer to it using the relative
|
---|
611 | path specified in \c example.qrc:
|
---|
612 |
|
---|
613 | \snippet doc/src/snippets/declarative/qtbinding/resources/main.qml 0
|
---|
614 |
|
---|
615 | To allow QML to locate resource files correctly, the \c main.cpp loads the main QML
|
---|
616 | file, \c main.qml, as a resource file using the \c qrc scheme:
|
---|
617 |
|
---|
618 | \snippet doc/src/snippets/declarative/qtbinding/resources/main.cpp 0
|
---|
619 |
|
---|
620 | Finally \c project.pro uses the RESOURCES variable to indicate that \c example.qrc should
|
---|
621 | be used to build the application resources:
|
---|
622 |
|
---|
623 | \quotefile doc/src/snippets/declarative/qtbinding/resources/resources.pro
|
---|
624 |
|
---|
625 | See \l {The Qt Resource System} for more information.
|
---|
626 |
|
---|
627 | */
|
---|
628 |
|
---|
629 |
|
---|