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
|
\l QQmlEngineExtensionPlugin is a plugin interface that lets you
create QML extensions that can be loaded dynamically into QML applications.
These extensions allow custom QML types to be made available to the
QML engine.
To write a QML extension plugin:
\list 1
\li Subclass \l QQmlEngineExtensionPlugin and use the Q_PLUGIN_METADATA() macro
to register the plugin with the Qt meta object system.
\li Use the \l QML_ELEMENT and \l QML_NAMED_ELEMENT() macros to declare
QML types.
\li Configure your build file.
CMake:
\badcode
qt_add_qml_module(<target>
URI <my.import.name>
VERSION 1.0
QML_FILES <app.qml>
NO_RESOURCE_TARGET_PATH
)
\endcode
qmake:
\badcode
CONFIG += qmltypes
QML_IMPORT_NAME = <my.import.name>
QML_IMPORT_MAJOR_VERSION = <version>
\endcode
\li If you're using qmake, create a
\l {Module Definition qmldir Files} {qmldir file} to describe the plugin.
Note that CMake will, by default, automatically generate the
\l {Module Definition qmldir Files} {qmldir file}.
\endlist
QML extension plugins are for either application-specific or library-like
plugins. Library plugins should limit themselves to registering types, as
any manipulation of the engine's root context may cause conflicts or other
issues in the library user's code.
\note When using the CMake \l qt_add_qml_module API, a plugin will be generated
automatically for you. It will take care of type registration.
You only need to write a custom plugin if you have special
requirements, such as registering custom image
providers. In that case, pass
\l{NO_GENERATE_PLUGIN_SOURCE} to the \c qt_add_qml_module
call to disable the generation of the default plugin.
The linker might erroneously remove the generated type registration
function as an optimization. You can prevent that by declaring a synthetic
volatile pointer to the function somewhere in your code. If your module is
called "my.module", you would add the forward declaration in global scope:
\code
void qml_register_types_my_module();
\endcode
Then add the following snippet of code in the implementation of any function
that's part of the same binary as the registration:
\code
volatile auto registration = &qml_register_types_my_module;
Q_UNUSED(registration);
\endcode
\section1 TimeExample QML Extension Plugin
Suppose there is a new \c TimeModel C++ class that should be made available
as a new QML type. It provides the current time through \c hour and \c minute
properties. It declares a QML type called \c Time via \l QML_NAMED_ELEMENT().
\snippet qmlextensionplugins/timemodel.h 0
\dots
To make this type available, create a plugin class named \c QExampleQmlPlugin,
which is a subclass of \l QQmlEngineExtensionPlugin. It uses the
Q_PLUGIN_METADATA() macro in the class definition to register the plugin with
the Qt meta object system using a unique identifier for the plugin.
\snippet qmlextensionplugins/plugin.cpp plugin
\section1 Build Settings for the Plugin
The build file defines the project as a plugin library, specifies it should be
built into the \c imports/TimeExample directory, and registers the plugin
target name.
\section2 Using CMake:
\snippet qmlextensionplugins/CMakeLists.txt 0
\snippet qmlextensionplugins/CMakeLists.txt 1
\section2 Using qmake:
\code
TEMPLATE = lib
CONFIG += qt plugin qmltypes
QT += qml
QML_IMPORT_NAME = TimeExample
QML_IMPORT_MAJOR_VERSION = 1
DESTDIR = imports/$$QML_IMPORT_NAME
TARGET = qmlqtimeexampleplugin
SOURCES += qexampleqmlplugin.cpp
\endcode
This registers the \c TimeModel class, with the import \c{TimeExample 1.0}, as
a QML type called \c Time. The \l{Defining QML Types from C++} article has more
information about registering C++ types for usage in QML.
\section1 Plugin Definition in the qmldir
Finally, a \l {Module Definition qmldir Files} {qmldir file} is required
in the \c imports/TimeExample directory to describe the plugin and the types
that it exports. The plugin includes a \c Clock.qml file along with the
\c qmlqtimeexampleplugin that is built by the project.
CMake will, by default, automatically generate this file. For more
information, see \l {Auto-generating qmldir and typeinfo files}.
When using qmake, specify the following in the \c qmldir file:
\quotefile qmlextensionplugins/imports/TimeExample/qmldir
To make things easier for this example, the TimeExample source directory is in
\c{imports/TimeExample}, and we build
\l{Source, Build, and Install Directories}{in-source}. However, the structure
of the source directory is not important, as the \c qmldir file can specify
paths to installed QML files.
What is important is the name of the directory that the qmldir is installed
into. When the user imports our module, the QML engine uses the
\l{Contents of a Module Definition qmldir File}{module identifier}
(\c TimeExample) to find the plugin, so the directory in which it is
installed must match the module identifier.
Once the project is built and installed, the new \c Time component is
accessible by any QML component that imports the \c TimeExample
module.
\snippet qmlextensionplugins/plugins.qml 0
The full source code is available in the \l {qmlextensionplugins}{plugins example}.
|
