diff options
Diffstat (limited to 'src/qml/doc/src/cppintegration')
| -rw-r--r-- | src/qml/doc/src/cppintegration/definetypes.qdoc | 41 | ||||
| -rw-r--r-- | src/qml/doc/src/cppintegration/extending-tutorial.qdoc | 30 |
2 files changed, 36 insertions, 35 deletions
diff --git a/src/qml/doc/src/cppintegration/definetypes.qdoc b/src/qml/doc/src/cppintegration/definetypes.qdoc index fd03cfc758..12da901e4c 100644 --- a/src/qml/doc/src/cppintegration/definetypes.qdoc +++ b/src/qml/doc/src/cppintegration/definetypes.qdoc @@ -78,8 +78,9 @@ class instance can be manipulated from QML; as Types to QML} explains, the properties, methods and signals of any QObject-derived class are accessible from QML code. -To register a QObject-derived class as an instantiable QML object type, call the -qmlRegisterType() function with the appropriate class and module URI. +To register a QObject-derived class as an instantiable QML object type, call +qmlRegisterType() to register the class as QML type into a particular type +namespace. Clients can then import that namespace in order to use the type. For example, suppose there is a \c Message class with \c author and \c creationDate properties: @@ -96,16 +97,16 @@ public: \endcode This type can be registered by calling qmlRegisterType() with an appropriate -module URI and version number. For example, to make the type available in a -module \c com.mycompany.messaging with version 1.0: +type namespace and version number. For example, to make the type available in +the \c com.mycompany.messaging namespace with version 1.0: \code qmlRegisterType<Message>("com.mycompany.messaging", 1, 0, "Message"); \endcode -The type can be used in an \l{qtqml-syntax-basics.html#object-declarations}{object declaration} -from QML, and its properties can be read and written to, as per the example -below: +The type can be used in an \l{qtqml-syntax-basics.html#object-declarations} +{object declaration} from QML, and its properties can be read and written to, +as per the example below: \qml import com.mycompany.messaging 1.0 @@ -215,7 +216,7 @@ Item { \code // MyType.qml -import MyModule 1.0 +import MyTypes 1.0 CppType { value: root.x @@ -225,14 +226,14 @@ CppType { where \c CppType maps to the C++ class \c CppType. If the author of CppType adds a \c root property to CppType in a new -version of the module, \c root.x now resolves to a different value because -\c root is also the \c id of the top level component. The author could +version of their type definition, \c root.x now resolves to a different value +because \c root is also the \c id of the top level component. The author could specify that the new \c root property is available from a specific minor version. This permits new properties and features to be added to existing elements without breaking existing programs. The REVISION tag is used to mark the \c root property as added in revision 1 -of the class. Methods such as Q_INVOKABLE's, signals and slots can also be +of the type. Methods such as Q_INVOKABLE's, signals and slots can also be tagged for a revision using the \c Q_REVISION(x) macro: \code @@ -254,13 +255,13 @@ template<typename T, int metaObjectRevision> int qmlRegisterType(const char *uri, int versionMajor, int versionMinor, const char *qmlName) \endcode -To register \c CppType version 1 for \c {MyModule 1.1}: +To register \c CppType version 1 for \c {MyTypes 1.1}: \code -qmlRegisterType<CppType,1>("MyModule", 1, 1, "CppType") +qmlRegisterType<CppType,1>("MyTypes", 1, 1, "CppType") \endcode -\c root is only available when MyModule 1.1 is imported. +\c root is only available when \c MyTypes version 1.1 is imported. For the same reason, new elements introduced in later versions should use the minor version argument of qmlRegisterType. @@ -271,8 +272,8 @@ should always remember to document what changed between minor versions, and QML module users should check that their application still runs correctly before deploying an updated import statement. -You may also register the revision of a base class that your module depends upon -using the qmlRegisterRevision() function: +You may also register the revision of a base class that your type depends +upon using the qmlRegisterRevision() function: \code template<typename T, int metaObjectRevision> @@ -283,14 +284,14 @@ int qmlRegisterUncreatableType(const char *uri, int versionMajor, int versionMin \endcode For example, if \c BaseType is changed and now has a revision 1, you can -specify that your module uses the new revision: +specify that your type uses the new revision: \code -qmlRegisterRevision<BaseType,1>("MyModule", 1, 1); +qmlRegisterRevision<BaseType,1>("MyTypes", 1, 1); \endcode -This is useful when deriving from base classes not declared as part of your -module, e.g. when extending classes from the QtQuick library. +This is useful when deriving from base classes provided by other authors, +e.g. when extending classes from the QtQuick library. \section1 Defining QML-Specific Types and Attributes diff --git a/src/qml/doc/src/cppintegration/extending-tutorial.qdoc b/src/qml/doc/src/cppintegration/extending-tutorial.qdoc index 3a9c5d1579..28c310e495 100644 --- a/src/qml/doc/src/cppintegration/extending-tutorial.qdoc +++ b/src/qml/doc/src/cppintegration/extending-tutorial.qdoc @@ -78,8 +78,8 @@ several custom QML types connected together through QML features like bindings a signals, and made available to the QML runtime through a plugin. To begin with, let's create a new QML type called "PieChart" that has two properties: a name -and a color. We will make it available in a \l {Modules}{module} called "Charts", with -a module version of 1.0. +and a color. We will make it available in an importable type namespace called "Charts", with +a version of 1.0. We want this \c PieChart type to be usable from QML like this: @@ -144,8 +144,8 @@ Here is the application \c main.cpp: \snippet examples/tutorials/extending/chapter1-basics/main.cpp 0 -This call to qmlRegisterType() registers the \c PieChart type as a type called "PieChart", in a module named "Charts", -with a module version of 1.0. +This call to qmlRegisterType() registers the \c PieChart type as a type called "PieChart", +in a type namespace called "Charts", with a version of 1.0. Lastly, we write a \c .pro project file that includes the files and the \c declarative library: @@ -327,7 +327,7 @@ item when its contents are drawn: Like the \c PieChart type, the \c PieSlice type has to be registered using qmlRegisterType() to be used from QML. As with \c PieChart, we'll add the -type to the "Charts" module, version 1.0: +type to the "Charts" type namespace, version 1.0: \snippet examples/tutorials/extending/chapter4-customPropertyTypes/main.cpp 0 \dots @@ -398,8 +398,8 @@ Currently the \c PieChart and \c PieSlice types are used by \c app.qml, which is displayed using a QQuickView in a C++ application. An alternative way to use our QML extension is to create a plugin library to make it available to the QML engine. This would allow the \c PieChart and \c PieSlice types to be -imported as part of a module by any QML application, instead of restricting these -types to be only used by the one application. +registered into a type namespace which could be imported by any QML application, +instead of restricting these types to be only used by the one application. The setps for creating a plugin are described in \l {Creating C++ Plugins for QML}. To start with, we create a plugin class named \c ChartsPlugin. It subclasses QQmlExtensionPlugin @@ -418,23 +418,23 @@ and specifies with DESTDIR that library files should be built into a "lib" subdi \quotefile examples/tutorials/extending/chapter6-plugins/chapter6-plugins.pro -Finally, we add a \l{Adding Module Metadata with a qmldir file}{qmldir} file that is -automatically parsed by the QML engine. In this file, we specify that a plugin named +Finally, we add a \l{qtqml-modules-qmldir.html}{qmldir} file that is +parsed by the QML engine. In this file, we specify that a plugin named "chapter6-plugin" (the name of the example project) can be found in the "lib" subdirectory: \quotefile examples/tutorials/extending/chapter6-plugins/ChartsPlugin/qmldir Now we have a plugin, and instead of having a main.cpp and an executable, we can build -the project and then load the QML file using the \l{Prototyping with qmlscene}{qmlscene tool}: +the project and then load the QML file using the \l{Prototyping with qmlscene}{qmlscene tool}, +setting the import path to the current directory so that it finds the \c qmldir file: \code - qmlscene app.qml + qmlscene -I . app.qml \endcode -Notice the "import Charts 1.0" statement has disappeared from \c app.qml. This is -because the \c qmldir file is in the same directory as \c app.qml: this is equivalent to -having PieChart.qml and PieSlice.qml files inside the project directory, which could both -be used by \c app.qml without import statements. +The module "Charts" will be loaded by the QML engine, and the types provided by that +module will be available for use in any QML document which imports it. + */ |