QML Syntax1.QML Basic Syntax1.1 Import Declarations
The import claim allows the client to tell the QML engine which modules, JavaScript resources, and component catalogs can be used in the QML document. The types you can use in your document depend on the modules, resources, and directories that you import into your document.
Import type
There are three different types of imports. There is a slight syntactic difference in each type of import, and different import types have different semantics.
* Import of modules (namespaces)
The most common type of import is module import. Clients can import QML modules that have registered QML object types and JavaScript resources into a given namespace.
The most common format for importing modules is as follows:
A) <ModuleIdentifier> specified in URI format to uniquely indicate the type namespace provided by the module
b) <Version.Number> is majorversion.minorversion the module version number in the following format
c) <Qualifier> is an optional, local namespace identifier. Both the object type of the module and the JavaScript resource are installed in this namespace. If not specified, the module's object type and JavaScript resources are installed to the global namespace.
A module that does not use qualifiers imports the declaration as follows:
This import example allows the consumer to use all the types provided by the Qtquick module without specifying qualifiers. For example, a client can create a rectangular region as follows:
An example of an import declaration that uses a qualifier is as follows:
Note: If a QML document uses an object type that is not imported by the module, an error will be generated. For example, the following document did not import Qtquick but tried to use the rectangle type:
In this case, the QML engine will trigger an error and refuse to load the qml file.
"Import of non-module namespaces"
Types can be registered directly in a namespace through a variety of registration methods in C + + (for example, Qmlregistertype ()). If the type is registered in a namespace this way, and the namespace is the identifier of the module, then we can import that type by importing the namespace.
"Import to a locally qualified namespace"
The import declaration optionally uses the AS keyword to import the type into a valid local namespace for the specified document scope. If a namespace is specified, then the use of these types must be preceded by the qualifier as a prefix.
Below, the Qtquick module is imported into the namespace "Coreitems". Now, any reference to the type in the Qtquick module must be prefixed with the Coreitems name:
A namespace is like the identifier of a module within a file. A namespace cannot be a property of a root object, and the root object can use properties, signals, and methods.
Namespace import is useful in cases where the QML object with the same name is provided in two different modules. In this case we can import two modules into two different local namespaces to ensure that the code can refer to the desired type.
Note: Multiple modules can be imported into the same namespace, and many modules can be imported into the global namespace. For example:
* Import of Catalogs
We can import the directory containing the QML document into the QML document. This provides a way to reuse QML types: Directories on the file system
The general form of the import catalog is as follows:
Note: The imported path is network-transportable: The application can import the remote path as if it were importing a local path. You can view the rules for URL resolution in the QML Document Network Transport Section. If you are importing a remote directory, then it must contain a directory Import list file, because if the Qmldir file does not exist, then the QML engine will not be able to identify the contents of the remote directory.
The semantics of <Qualifier> are the same as those described earlier. For This type of import, see "Catalog Import" for updated information.
"Catalog Import"
A local directory containing the QML file can be imported directly without any additional configuration. A remote directory containing QML files can also be imported, but requires a directory listing Qmldir file exists. A local directory can also have an optional directory listing Qmldir file that defines the type names that must be imported to the client and specifies the JavaScript resources that must be imported to the client.
"Local Directory Import"
Any QML file on the local file system can be imported into the local directory using the import declaration and the absolute or relative path of the directory, allowing the QML file to use the object system defined in that directory.
If the local directory contains a directory listing Qmldir file, the object type specified in the Qmldir file can be used, otherwise the file name from the QML document will be used as the type name. If there are no Qmldir files in the directory, then only those filenames begin with an uppercase letter, and the file name ending with ". Qml" will be the object type.
Example:
Consider the following QML engineering directory structure. Under the top-level directory MyApp, there is a subdirectory for the public UI component Mycomponents, the main program code under subdirectory main:
The main/application.qml file can be imported using a relative path to the Mucomponents directory, allowing the application to use the QML object type under that directory:
You can also specify a qualifier when importing the directory:
It is convenient to import local paths, but when the directory location changes, we have to update the import declarations in the application. However, this can also be avoided through the QML module, because an installed module can be imported with a single, deterministic string, without the need for a file system path.
"Remote Directory Import"
If the remote directory contains a directory listing Qmldir file, the Qml file can also be imported into the remote directory.
For example, if the previous application MyApp directory is stored in "http://www.my-example-server.com", the Mycomponents directory contains the Qmldir file as defined below:
Next, we can use the URL to import the Mycomponents remote directory:
Note: When importing a remote directory, we can only access the QML and JavaScript files declared in the Qmldir file.
Warning: When importing a remote directory, developers must be very careful to load only those trusted resources and should avoid loading illegal code.
"Directory list Qmldir file"
The directory list file Qmldir differs from the module definition qmldir file. Directory listing Qmldir files allow a fast and simple sharing of a set of QML documents, but it does not define a type namespace in the document, nor does IT support QML object type versions.
The directory listing Qmldir file syntax is as follows:
The difference between the above two lines is that the object type can be used by a QML document that does not have a internal to import the directory, whereas the containing internal represents this part of the object type as internal and not for use by clients.
A local directory can optionally contain the Qmldir file. This allows the engine to simply expose the object types and JavaScript resources explicitly listed in the Qmldir file to the client.
[Import Directory Example] (QTDECLARATIVE\EXAMPLES\QUICK\TUTORIALS\GETTINGSTARTEDQML)
Import of *javascript Resources
JavaScript resources can be imported directly into the QML document. Each JavaScript resource must have an identifier that indicates a reference to the resource.
The generic JavaScript resource import declaration is as follows:
Note: <Identifier> here must be unique in the document, not as a local namespace can be applied to multiple modules of import.
JavaScript resources in the module
The module can provide JavaScript files by adding JavaScript resource identifiers to the Qmldir file that identifies the module.
For example, if projects. The Myqmlproject.myfunctions module is specified with the following Qmldir file and is installed in the QML import path:
Then an application can import the JavaScript resources by importing the module, and use the JavaScript resource identifiers to reference JavaScript resources:
If the module is imported into a local namespace, the qualifier for the local namespace before the JavaScript resource identifier can refer to the JavaScript resource as follows:
More information
For more information on JavaScript resources, see document defining JavaScript Resources in QML, how to import JavaScript resources, and how to use imports in JavaScript resources. You can see the document import JavaScript resources in QML.
[JavaScript Resource Import Example] (Qtdeclarative\examples\quick\demos\photoviewer)
QML Import Path
When the installed module is imported, the QML engine will search for the matching module in the import path.
The import path can be obtained using the Qqmlengine::importpathlist () method, which defines the path to the engine's default search. By default, it contains:
² directory where the current file is located
² Path specified by Qlibraryinfo::qml2importspath
² path specified by the environment variable Qml2_import_path
We can add the import path via Qqmlengine::addimportpath () or environment variable Qml2_import_path. When executing the Qmlscene tool, you can also add the import path using the-i option.
Debugging
It is useful to qml_import_trace environment variables when looking for and loading module errors. You can view the module import debugging for more information.
"Summary"
QML is a declarative language that allows you to define the properties of objects and objects, and how they interact with other objects. In comparison with native code, the change of attributes and states in native code is passed through a series of processing, but the declarative QML language integrates attributes and state changes directly in the independent object.
The QML source code is typically loaded by the QML engine via the QML document, and the QML engine and QML code are separated. This allows us to define reusable QML object types.
The beginning of a QML document may have one or more import declarations. An import claim may be one of the following:
* A namespace with a version number, where objects are registered in the namespace (for example, plug-ins)
* A related directory containing the QML document definition type
* A JavaScript document
Note: When you import a JavaScript document, you must make a qualifier so that we can reference the properties and methods it provides.
The general import type is as follows:
For example:
1.2 Object Declaration
A QML code block defines the Qml object tree that will be created. Objects are defined using object declarations, and object declarations describe the type of object and the properties that are given to that object. Each object can define a child object using nested declaration syntax.
A simple object is declared as follows:
An object of type rectangle is declared in the example above, followed by a pair of parentheses enclosing the object's properties. The rectangle object is provided by the Qtquick module, and the three properties defined here are also rectangle width,height and color properties.
If the declaration of the above object is part of the QML document, it can be loaded by the QML engine. However, the document must be imported into the Qtquick module:
Save the above content into a. qml file and load it using the QML engine, the effect is as follows:
Note: If you define an object that has only a few properties, you can write it like this on one line, separating the attributes with semicolons:
Obviously, the rectangle object defined in this example is very simple, just defining several of its property values. To create more useful objects, an object may have many properties: This is described in the Qml object properties document. In addition, an object may contain sub-objects, which we will discuss below.
1.2.1 Child Objects
Any object can declare child objects through nested objects. In this case, the declaration of any object implicitly declares an object tree that may contain any number of child objects.
For example, a declaration of an rectangle object can contain a declaration of an gradient object, and the Gradient object contains a declaration of two GradientStop objects:
When this code is loaded by the QML engine, the QML engine creates an object tree with rectangle as its root object, which has a gradient child object that contains two GradientStop sub-objects.
Note: Objects in the context of the QML object tree are parent-child relationships that are not parent-child relationships in the context of a visual scene. The parent-child relationship in a visual scene is expressed by the item type provided by the Qtquick module, and the item type is the base type of the QML type, because the vast majority of QML objects will be rendered. For example: Rectangle and text are objects based on the item type, and in the following example text is declared as a visual sub-object of the Rectangle object:
In the above code, if the text object refers to its father's value, it refers to the father in its visual scene, not the father in the object tree. In this example, they are the same: at this point, rectangle is both the text and the parent object in the visual scene of the text in the object tree. However, the Father attribute can be modified to alter the parent object in the visual scene, and we cannot modify it in QML to modify the parent object in the object tree context.
Also, note that the text object is not declared as a property of rectangle, unlike the previous example where the gradient object is a gradient attribute that is specified as rectangle. This is because the child property of item is set directly to the default property of that type, which makes the syntax simpler.
You can view the visual parent object document to get more conceptual information about the visual parent object for the item type.
1.3 Notes
Comments in QML are very similar to those in javascript:
* A single line of comments is to//start until the end of the line;
* Multiline comment starts with/* and ends with */
The QML engine ignores annotation information when it processes the QML code.
Interpreting the three QML