summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorMartin Jones <martin.jones@nokia.com>2009-05-05 23:55:01 (GMT)
committerMartin Jones <martin.jones@nokia.com>2009-05-05 23:55:01 (GMT)
commitf6e9e3ccfd5cedcdba5a0d4b606e1c794b3ea640 (patch)
tree576851d9ddbb1c695d2207a6ce386c2d34fc17f5 /doc
parent1f627ce25cc14b0bec85a71bd5a186e936bd4771 (diff)
parentf98a10ed41f181252d83e9cebaa3772d556f6266 (diff)
downloadQt-f6e9e3ccfd5cedcdba5a0d4b606e1c794b3ea640.zip
Qt-f6e9e3ccfd5cedcdba5a0d4b606e1c794b3ea640.tar.gz
Qt-f6e9e3ccfd5cedcdba5a0d4b606e1c794b3ea640.tar.bz2
Merge branch 'kinetic-declarativeui' of git@scm.dev.nokia.troll.no:qt/kinetic into kinetic-declarativeui
Diffstat (limited to 'doc')
-rw-r--r--doc/src/declarative/qmlforcpp.qdoc774
-rw-r--r--doc/src/declarative/qtdeclarative.qdoc2
-rw-r--r--doc/src/declarative/scenegraph.qdoc13
-rw-r--r--doc/src/images/declarative-reuse-1.pngbin0 -> 3489 bytes
-rw-r--r--doc/src/images/declarative-reuse-2.pngbin0 -> 3700 bytes
-rw-r--r--doc/src/images/declarative-reuse-3.pngbin0 -> 8829 bytes
-rw-r--r--doc/src/images/declarative-reuse-bluerect.pngbin0 -> 1474 bytes
-rw-r--r--doc/src/images/declarative-reuse-focus.pngbin0 -> 8026 bytes
-rw-r--r--doc/src/tutorials/declarative.qdoc272
9 files changed, 399 insertions, 662 deletions
diff --git a/doc/src/declarative/qmlforcpp.qdoc b/doc/src/declarative/qmlforcpp.qdoc
index f0675fe..282f261 100644
--- a/doc/src/declarative/qmlforcpp.qdoc
+++ b/doc/src/declarative/qmlforcpp.qdoc
@@ -1,15 +1,14 @@
/*!
\page qmlforcpp.html
\target qmlforcpp
- \title Qt Declarative Markup Language For C++ Programmers
+ \title QML for C++ Programmers
This page describes the QML format and how to use and extend it from C++.
- The QML syntax declaratively describes in XML how to construct an in memory
- object tree. QML is usually used to describe a visual scene graph - using
- \l {graphicsview}{GraphicsView} or the \l {fxprimitives}{Fx Primitives} - but it is not conceptually
- limited to this: the QML format is an abstract XML description of \b any
- object tree.
+ The QML syntax declaratively describes how to construct an in memory
+ object tree. QML is usually used to describe a visual scene graph
+ but it is not conceptually limited to this: the QML format is an abstract
+ description of \b any object tree.
QML also includes property bindings. Bindings are ECMAScript expressions
of a properties value. Whenever the value of the expression changes -
@@ -27,58 +26,40 @@
The following code uses the C++ interface to create 100 red rectangles
based on a simple declarative component description.
- \raw html
- <table border="0">
- <tr>
- <td>
- \endraw
+
\code
- QmlComponent redRectangle("<Rect color=\"red\" width=\"100\" height=\"100\" />");
+ QmlComponent redRectangle("Rect { color: \"red\"; width: 100; height: 100 }");
for (int ii = 0; ii < 100; ++ii) {
QObject *rectangle = redRectangle.create();
// ... do something with the rectangle ...
}
\endcode
- \raw html
- </td>
- </tr>
- </table>
- \endraw
- Each independent XML file describes a QML component, but it is
- also possible to create sub-components within a QML file as will be
- shown later.
+ Each independent file describes a QML component, but it is also possible to
+ create sub-components within a QML file as will be shown later.
\section1 QML Format 101
This is some sample QML code.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
- <Image id="myRect" x="10" y="10" width="100" height="100" src="background.png">
- <Text width="100">
- <height>50</height>
- <color>white</color>
- <font.fontSize>16</font.fontSize>
- Hello world!
- </Text>
- </Image>
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
-
- In QML, XML tags and attributes correspond to Qt objects and properties.
- The general rule of thumb is any tag or attribute name that starts with a
- capital letter refers to a class, and names that start with a lower case
- letter to properties. It is not possible to access a property that starts
- with a capital letter from QML.
+ Image {
+ id: myRect
+ x: 10
+ y: 10
+ width: 100
+ height: 100
+ src: "background.png"
+
+ Text {
+ height: 50
+ width: 100
+ color: "white"
+ font.fontSize: 16
+ text: "Hello world!"
+ }
+ }
+ \endcode
The QML snippet shown above instantiates one \c Image instance and one
\c Text instance and sets properties on both. \b Everything in QML
@@ -86,50 +67,18 @@
assigning a property a value. QML relies heavily on Qt's meta object system
and can only instantiate classes that derive from QObject.
- Setting properties can be done in two ways: as an XML attribute directly on
- the class tag that created the the object, or as sub-tags.
- Although syntactically different, their behaviour is identical. The two QML
- snippets below behave exactly the same.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
- \code
- <Rect x="10" y="10" />
- \endcode
-\raw HTML
- </td>
- <td>
-\endraw
- \code
- <Rect>
- <x>10</x>
- <y>10</y>
- </Rect>
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
- Arbitrary mixing and matching between the two is allowed.
-
QML can set properties that are more complex than just simple types like
- integers and strings. Properties can be object pointers or Qt interface pointers
- or even lists of object or Qt interface pointers! QML is typesafe, and will
- ensure that only the valid types are assigned to properties.
+ integers and strings. Properties can be object pointers or Qt interface
+ pointers or even lists of object or Qt interface pointers! QML is typesafe,
+ and will ensure that only the valid types are assigned to properties.
Assigning an object to a property is as simple as assigning a basic
integer. Attempting to assign an object to a property when type coercian
fails will produce an error. The following shows an example of valid and of
invalid QML and the corresponding C++ classes.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
+ \table
+ \row \o
\code
class Image : public QObject
{
@@ -142,86 +91,33 @@
...
};
\endcode
-\raw HTML
- </td>
- <td>
-\endraw
- \code
- <!-- OK -->
- <Image>
- <filter>
- <ImageFilter />
- </filter>
- </Image>
-
- <!-- NOT OK: Image cannot be cast into ImageFilter -->
- <Image>
- <filter>
- <Image />
- </filter>
- </Image>
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
+ \o \code
+ // OK
+ Image {
+ filter: ImageFilter {}
+ }
- Classes can also define an optional default property. The default property
- is used for assignment if no explicit property has been specified.
- In the example below, the string "Hello World!" will be assigned to
- the \c Text element's default property - which happens to be the \c text
- property. Both lines do the same thing, one explicitly and one implicitly.
-
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
- \code
- <Text text="Hello World!" />
- <Text>Hello World!</Text>
- \endcode
-\raw HTML
- </td>
- <td>
-\endraw
- \code
- class Text : public QObject
- {
- ...
- Q_PROPERTY(QString text READ text WRITE setText)
- Q_CLASSINFO("DefaultProperty", "text")
- };
+ // NOT OK: Image cannot be cast into ImageFilter
+ Image {
+ filter: Image {}
+ }
\endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
+ \endtable
+ Classes can also define an optional default property. The default property
+ is used for assignment if no explicit property has been specified.
Any object property can be the default, even complex properties like lists
of objects. The default property of the \c Rect class is the \c children
property, a list of \c Item's. In the following example, as both \c Image
and \c Text inherit from \c Item the \c Image and \c Text instances are
added to the parent's \c children property.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
- <Rect>
- <Image />
- <Text />
- </Rect>
+ Rect {
+ Image {}
+ Text {}
+ }
\endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
Properties that return read-only object pointers can be used recursively.
This can be used, for example, to group properties together. The
@@ -230,11 +126,8 @@
QML makes it easy to interact with these grouped properties, as the
following shows - everything you would expect to work, just does.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
+ \table
+ \row \o
\code
class Text : public ...
{
@@ -250,67 +143,36 @@
Q_PROPERTY(int size READ size WRITE setSize);
};
\endcode
-\raw HTML
- </td>
- <td>
-\endraw
+ \o
\code
- <Text font.family="helvetica">
- <font>
- <bold>true</bold>
- <italic>true</italic>
- </font>
- <font.size>12</font.size>
- </Text>
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
+ Text {
+ font.family: "helvetica"
+ font.size: 12
+ font {
+ bold: true
+ italic: true
+ }
+ }
+ \endcode
+ \endtable
\section1 Defining QML Types
The QML engine has no intrinsic knowledge of any class types. Instead
the programmer must define the C++ types, and their corresponding QML
- name. There are three ways of adding known types to the QML engine:
- \list
- \o
+ name.
+
\code
#define QML_DECLARE_TYPE(T)
#define QML_DEFINE_TYPE(T,QmlName)
\endcode
+
Adding these macros to your library or executable automatically makes the
C++ type \a T available from the declarative markup language under the
name \a QmlName. Of course there's nothing stopping you using the same
- name for both the C++ and the QML name!<br>
- Most types are added to the QML engine using these macros. The only
- requirement is that \a T inherits QObject and has a default constructor.
- \o
- \code
- #define QML_DEFINE_CUSTOM_PARSER(QmlName, CustomParserClass)
- \endcode
- Custom parsers define a way to translate between declarative XML and an
- object instance in the case the default object model lets you down. Free
- form lists (\c {<ListModel>} are an example of a custom parser.
- Custom parsers implement the \l QmlCustomParser interface.
-
- Custom parsers give a developer very fine grain control over how a type is
- instantiated from the XML that describes it. During the
- compilation phase, the custom parser is presented with the XML via a
- QXmlStreamReader and must
- compile this down into an opaque blob that is returned to the compiler.
- When, at runtime, the type is instantiated, the opaque blob is passed into
- the custom parser, which must return a QObject derived type.
-
- \o QML::ClassFactory
-
- The QML engine calls the class factory as a last resort when trying to
- create a type. The class factory returns a \l QmlComponent instance for
- the type if it can create it. This allows "on the fly" types to be created.
- For example, a class factory is used to support automatic instantiation of
- .qml template files.
- \endlist
+ name for both the C++ and the QML name!
+ Any type can be added to the QML engine using these macros. The only
+ requirements are that \a T inherits QObject and that it has a default constructor.
\section1 Property Binding
@@ -321,31 +183,32 @@
Property bindings are ECMAScript expressions and can be applied to any
object property. C++ classes don't have to do anything special to get
- binding support other than define appropriate properties. Property binding
- expressions are differentiated from regular constant literals by surrounding
- them in braces.
+ binding support other than define appropriate properties. When a non-literal
+ property assignment appears in a QML file, it is automatically treated as a
+ property binding.
Here's a simple example that stacks a red, blue and green rectangle.
Bindings are used to ensure that the height of each is kept equal to it's
parent's. Were the root rectangle's height property to change, the child
rectangles height would be updated automatically.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
+
\code
- <Rect color="red" width="100">
- <Rect color="blue" width="50" height="{parent.height}">
- <Rect color="green" width="25" height="{parent.height}">
- </Rect>
- </Rect>
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
+ Rect {
+ color: "red"
+ width: 100
+ Rect {
+ color: "blue"
+ width: 50
+ height: parent.height
+ Rect {
+ color: "green"
+ width: 25
+ height: parent.height
+ }
+ }
+ }
+ \endcode
+
Binding expressions execute in a context. A context behaves as a scope and
defines how the expression resolves property and variable names. Although
the two expressions in the last example are the same, the value of \c parent
@@ -371,24 +234,14 @@
the case of grouped properties - the object context is that of the
instantiated object, the consequences of which are shown below.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
- <!-- OK --> <!-- NOT OK: Text has no italic property -->
- <Text> <Text>
- <font> <font>
- <bold>{font.italic}</bold> <bold>{italic}</bold>
- </font> </font>
- </Text> </Text>
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
+ // OK // NOT OK
+ Text { Text {
+ font { font {
+ bold: font.italic bold: italic
+ } }
+ } }
+ \endcode
The second context is the "component context". Each QML component (and
consequently each QML file) is created in its own unique binding context.
@@ -396,21 +249,14 @@
object - but in this case it is the component's root object. An example
will illustrate best - the resultant text will read "background.png".
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
- <Image src="background.png">
- <Text text="{src}" />
- </Image>
+ Image {
+ src: "background.png"
+ Text {
+ text: src
+ }
+ }
\endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
If the name is not found in either of these contexts, the context heirarchy
is searched parent-by-parent until the name is either found, or the
@@ -421,23 +267,22 @@
parent, rather than fixing them all to a single common point. Here's the
example rewritten to do just that.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
- <Rect color="red" width="100">
- <Rect color="blue" width="50" height="{parent.height}">
- <Rect color="green" width="25" height="{parent.parent.height}">
- </Rect>
- </Rect>
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
+ Rect {
+ color: "red"
+ width: 100
+ Rect {
+ color: "blue"
+ width: 50
+ height: parent.height
+ Rect {
+ color: "green"
+ width: 25
+ height: parent.parent.height
+ }
+ }
+ }
+ \endcode
Clearly this sort of fragile relationship is undesirable and unmanageable -
moving the green rectangle to be a sibling of the blue or introducing a
@@ -450,28 +295,26 @@
property. Every object automatically has this magical property (if the
object also has an actual property called \c id, that gets set too). As
an id allows an object to be referenced directly, it must be unique within
- a component. Any number of id's can exist, but they must all begin with
- a capital letter. An id of "Root" is valid, while an id of "root" is not.
- \note This is not technically true - lowercase id names do work, but are
- slower. Support will probably be removed for them eventually.
-
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
- \code
- <Rect id="Root" color="red" width="{GreenRect.width + 75}">
- <Rect color="blue" width="{GreenRect.width + 25}" height="{Root.height}">
- <Rect id="GreenRect" color="green" width="25" height="{Root.height}">
- </Rect>
- </Rect>
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
+ a component. By convention, id's should start with an uppercase letter.
+
+ \code
+ Rect {
+ id: Root
+ color: "red"
+ width: GreenRect.width + 75
+ height: Root.height
+ Rect {
+ color: "blue"
+ width: GreenRect.width + 25
+ Rect {
+ id: GreenRect
+ color: "green"
+ width: 25
+ height: Root.height
+ }
+ }
+ }
+ \endcode
To relate id's back to QmlBindContext, id's exist as properties on the
component context.
@@ -483,11 +326,6 @@
the expression will not be updated if the value changes. The following is
an example of a QML friendly property declaration.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
class Example : public QObject
{
@@ -500,11 +338,6 @@
void sampleChanged(int);
};
\endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
While generally no changes are needed to a C++ class to use property
binding, sometimes more advanced interaction between the binding engine and
@@ -523,19 +356,12 @@
easily associate ECMAScript with signals. Consider the following example,
in which Button is a made-up type with a clicked() signal.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
- <Button text="Hello world!" onClicked="print(text)" />
+ Button {
+ text: "Hello world!"
+ onClicked: print(text)
+ }
\endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
Clicking on the button causes "Hello world!" to be printed to the console
(or lost forever if you're running Windows).
@@ -558,23 +384,15 @@
below, as long as you remember to name the parameters of your signal
in C++ (see QMetaMethod::parameterNames()).
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
+ \table
+ \row \o
\code
- <Example>
- <onDoSomething>
- for(var ii = 0; ii &lt; count; ++ii)
- print(message)
- </onDoSomething>
- </Example>
- \endcode
-\raw HTML
- </td>
- <td>
-\endraw
+ Example {
+ onDoSomething: for(var ii = 0; ii &lt; count; ++ii)
+ print(message)
+ }
+ \endcode
+ \o
\code
class Example : public QObject
{
@@ -583,11 +401,7 @@
void doSomething(int count, const QString &message);
};
\endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
+ \endtable
Just like property bindings, signal scripts are executed in a context. The
signal script context is identical in scope to the "object context" under
@@ -599,41 +413,23 @@
default method is defined just like a default property, though the special
"DefaultMethod" class info.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
Q_CLASSINFO("DefaultMethod", "myMethod(int)");
\endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
This is useful in achieving several use cases, like that below which moves
the button when it is clicked.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
- <Button id="MyButton">
- <onClicked>
- <NumericAnimation target="{MyButton}" property="x" to="100" />
- </onClicked>
- </Button>
+ Button {
+ id: MyButton
+ onClicked: NumericAnimation {
+ target: MyButton
+ property: "x"
+ to: 100
+ }
+ }
\endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
-
If the class itself actually defines a property called "on<Name>", this will
be assigned the string value and the signal handling behaviour will be
@@ -648,65 +444,44 @@
Qt's QGridLayout is one such example.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
- <QGridLayout>
- <QLabel QGridLayout.row="0" QGridLayout.column="0" text="Name:"/>
- <QLineEdit QGridLayout.row="0" QGridLayout.column="1" />
-
- <QLabel QGridLayout.row="1" QGridLayout.column="0" text="Occupation:"/>
- <QLineEdit QGridLayout.row="1" QGridLayout.column="1" />
- </QGridLayout>
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
+ QGridLayout {
+ QLabel {
+ QGridLayout.row: 0
+ QGridLayout.column: 0
+ text: "Name:"
+ }
+ QLineEdit {
+ QGridLayout.row: 0
+ QGridLayout.column: 1
+ }
+
+ QLabel {
+ QGridLayout.row: 1
+ QGridLayout.column: 0
+ text: "Occupation:"
+ }
+ QLineEdit {
+ QGridLayout.row: 1
+ QGridLayout.column: 1
+ }
+ }
+ \endcode
- Attached properties are identified by the use of a class name, in the
+ Attached properties are identified by the use of a type name, in the
case shown \c QGridLayout, as a grouped property specifier. To prevent
ambiguity with actual class instantiations, attached properties must
always be specified to include a period but can otherwise be used just like
regular properties.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
- \code
- <!-- OK --> <!-- NOT OK: Creates a QGridLayout, rather than assigning attached property -->
- <QLabel> <QLabel>
- <QGridLayout.row>0</QGridLayout.row> <QGridLayout>
- </QLabel> <row>0</row>
- </QGridLayout>
- </QLabel>
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
-
C++ types provide attached properties by declaring the public function \c qmlAttachedProperties like this example.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
+ \table
+ \row \o
\code
static QObject *Type::qmlAttachedProperties(QObject *);
\endcode
-\raw HTML
- </td>
- <td>
-\endraw
+ \o
\code
class Example : public QObject
{
@@ -715,18 +490,14 @@
static QObject *qmlAttachedProperties(QObject *);
};
\endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
+ \endtable
When an attached property is accessed, the QML engine will call this method
to create an attachment object, passing in the object instance that the
attached property applies to. The attachment object should define all
the attached properties, and is generally parented to the provided object
- instance to avoid memory leaks. The QML engine does not save this object,
- so it is necessary for the attached property function to ensure that
+ instance to avoid memory leaks. The QML engine does not saves this object,
+ so it is not necessary for the attached property function to ensure that
multiple calls for the same instance object return the same attached object.
While conceptually simple, implementing an attachment object is not quite
@@ -737,23 +508,15 @@
that \b any object can attach \b any attached property. The following is
perfectly valid, although the attached property has no actual effect:
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
- <FancyGridLayout>
- <Item>
- <Button QGridLayout.row="1" />
- </Item>
- </FancyGridLayout>
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
+ FancyGridLayout {
+ Item {
+ Button {
+ QGridLayout.row: 1
+ }
+ }
+ }
+ \endcode
The property has no effect because the (made-up) FancyGridLayout type defines the meaning
of the \c row attached property only to apply to its direct children. It
@@ -769,29 +532,17 @@
\section1 Property Value Sources
Intrinsically, the QML engine can assign a property either a static value,
- such as a number of object tree, or a property binding. It is possible for
+ such as a number or an object tree, or a property binding. It is possible for
advanced users to extend the engine to assign other "types" of values to
properties. These "types" are known as property value sources.
- Consider the following \l {fxprimitives}{Fx Primitives} example.
+ Consider the following example.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
- <Rect width="100" height="100" color="red">
- <x>
- <NumericAnimation running="true" repeat="true" from="0" to="100" />
- </x>
- </Rect>
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
+ Rect {
+ x: NumericAnimation { running: true; repeat; true; from: 0; to: 100; }
+ }
+ \endcode
Here the \c x property of the rectangle will be animated from 0 to 100.
To support this, the NumericAnimation class inherits the
@@ -805,26 +556,17 @@
QML is designed to allow you to build fully working types without writing
a line of C++ code. This is, for example, used extensively when designing
- applications using the \l {fxprimitives}{Fx Primitives}. To create new types, it is
+ applications using the Fluid UI primitives. To create new types, it is
necessary to be able to define new signals, slots and properties in QML.
- \note slots are not yet supported
-
- Any object is extensible in this way under QML, using the special
- \c properties and \c signals properties. Like \c id, these two properties
- are automatically available on all types under QML and accessible from
- other QML files or directly from C++.
-
In this example, a Button is extended to have an additional
"text2" property (which always returns "Hello world!") and an additional
signal "clicked2" that is also emitted when the button is clicked. Not
a very useful extension, but an extension nonetheless.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
+ \table
+ \row
+ \o
\code
QmlComponent component(xmlData);
QObject *object = component.create();
@@ -833,44 +575,36 @@
// Will be emitted whenever the button is clicked
QObject::connect(object, SIGNAL(clicked2()), this, SLOT(...));
\endcode
-\raw HTML
- </td>
- <td>
-\endraw
+ \o
\code
- <Button text="Hello!">
- <properties>
- <Property name="text2" type="string" />
- </properties>
- <signals>
- <Signal name="clicked2" />
- </signals>
- <text2>Hello world!</text2>
- <onClicked>clicked2.emit()</onClicked>
- </Button>
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
-
- Any number of properties and signals can be added to an existing type. The
- \c Property and \c Signal elements have the following properties that can
- be set:
- \table
- \header \o Tag \o Property \o Description
- \row \o Property \o name \o The name of the property
- \row \o Property \o type \o The type of the property. The available types are: \list \o int \o bool \o double \o real \o string \o color \o date \o variant \endlist The default is variant.
- \row \o Property \o value \o The initial value of the property. Setting this is just a shortcut for setting the property normally, as shown in the example above.
- \row \o Property \o onValueChanged \o A special signal property that is emitted each time the property value changes.
- \row \o Property \o default \o Set this as the object's default property
- \row \o Signal \o name \o The name of the signal.
+ Button {
+ property string text2
+ signal clicked2
+
+ text: "Hello!"
+ text2: "Hello world!"
+ onClicked: clicked2.emit()
+ }
+ \endcode
\endtable
- If the type itself actually defines a property called \c properties or
- \c signals, the respective extension will be disabled for that type and
- the types own properties will be set.
+ The general syntax for defining new properties and signals is:
+
+ \list
+ \o
+ \code
+ [default] property <type> <name> [: <default value>]
+ \endcode
+
+ Where type can be one of \e int, \e bool, \e double, \e real, \e string,
+ \e color, \e date, \e var or \e variant.
+
+ \o
+ \code
+ signal <name>
+ \endcode
+ Currently only parameterless signals are supported.
+ \endlist
\section1 Parser Status
@@ -890,11 +624,6 @@
these notifications, all a class has to do is to inherit the interface, and
notify the Qt meta system using the Q_INTERFACES() macro. For example,
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
class Example : public QObject, public QmlParserStatus
{
@@ -907,11 +636,6 @@
}
};
\endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
\section1 Extended Type Definitions
@@ -935,29 +659,17 @@
property or slots on the extension object is used instead.
When an extended type is installed, the
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
\code
#define QML_DEFINE_EXTENDED_TYPE(T,QmlName,ExtendedTypeName)
\endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
macro should be used instead of the regular \c QML_DEFINE_TYPE.
This example shows the addition of a read-only \c textLength property to
QLabel being implemented as an extension.
-\raw HTML
- <table border="0">
- <tr>
- <td>
-\endraw
+ \table
+ \row
+ \o
\code
class QLabelExtension : public QObject
{
@@ -971,19 +683,17 @@
};
QML_DEFINE_EXTENDED_TYPE(QLabel,QLabel,QLabelExtension);
\endcode
-\raw HTML
- </td>
- <td>
-\endraw
+ \o
\code
- <QLabel id="Label1" text="Hello World!" />
- <QLabel text="{'Label1 text length:' + Label1.textLength}" />
- \endcode
-\raw HTML
- </td>
- </tr>
- </table>
-\endraw
+ QLabel {
+ id: Label1
+ text: "Hello World!"
+ }
+ QLabel {
+ text: "Label1 text length: " + Label1.textLength
+ }
+ \endcode
+ \endtable
Attributes defined through extensions are inherited, just like attributes
defined on a normal class. Any types that inherit from \c QLabel, will
diff --git a/doc/src/declarative/qtdeclarative.qdoc b/doc/src/declarative/qtdeclarative.qdoc
index 666c8ae..67605dc 100644
--- a/doc/src/declarative/qtdeclarative.qdoc
+++ b/doc/src/declarative/qtdeclarative.qdoc
@@ -65,7 +65,7 @@
\o \l {qmlexamples}{Examples}
\o \l {tutorial}{Tutorial: 'Hello World'}
\o \l {tutorials-declarative-contacts.html}{Tutorial: 'Introduction to QML'}
- \o \l {qmlforcpp}{Qt Declarative Markup Language For C++ Programmers}
+ \o \l {qmlforcpp}{QML For C++ Programmers}
\endlist
Core Features:
diff --git a/doc/src/declarative/scenegraph.qdoc b/doc/src/declarative/scenegraph.qdoc
deleted file mode 100644
index 2340324..0000000
--- a/doc/src/declarative/scenegraph.qdoc
+++ /dev/null
@@ -1,13 +0,0 @@
-/*!
- \page graphicsview.html
- \target graphicsview
- \title GraphicsView
-
-*/
-
-/*!
- \page fxprimitives.html
- \target fxprimitives
- \title FX Primitives
-
-*/
diff --git a/doc/src/images/declarative-reuse-1.png b/doc/src/images/declarative-reuse-1.png
new file mode 100644
index 0000000..c704457
--- /dev/null
+++ b/doc/src/images/declarative-reuse-1.png
Binary files differ
diff --git a/doc/src/images/declarative-reuse-2.png b/doc/src/images/declarative-reuse-2.png
new file mode 100644
index 0000000..0b6006b
--- /dev/null
+++ b/doc/src/images/declarative-reuse-2.png
Binary files differ
diff --git a/doc/src/images/declarative-reuse-3.png b/doc/src/images/declarative-reuse-3.png
new file mode 100644
index 0000000..695a725
--- /dev/null
+++ b/doc/src/images/declarative-reuse-3.png
Binary files differ
diff --git a/doc/src/images/declarative-reuse-bluerect.png b/doc/src/images/declarative-reuse-bluerect.png
new file mode 100644
index 0000000..97dbb5f
--- /dev/null
+++ b/doc/src/images/declarative-reuse-bluerect.png
Binary files differ
diff --git a/doc/src/images/declarative-reuse-focus.png b/doc/src/images/declarative-reuse-focus.png
new file mode 100644
index 0000000..f91d374
--- /dev/null
+++ b/doc/src/images/declarative-reuse-focus.png
Binary files differ
diff --git a/doc/src/tutorials/declarative.qdoc b/doc/src/tutorials/declarative.qdoc
index bde71da..9b9c90f 100644
--- a/doc/src/tutorials/declarative.qdoc
+++ b/doc/src/tutorials/declarative.qdoc
@@ -97,10 +97,7 @@
\tableofcontents
The first part of this tutorial covers basic drawing of elements on the
- screen and causing them to animate. The file 1_Drawing_and_Animation.qml
- loads and displays each of the five stages of this tutorial in a single
- window. For now you don't need to worry about the contents of
- 1_Drawing_and_Animation.qml.
+ screen and causing them to animate.
\section1 Drawing
@@ -115,7 +112,9 @@
Because Declarative UI is declarative, you don't pass instructions on
what to paint in a sequential manner as you may be used to. Instead
elements and how they appear on the screen are declared in much the
- same was as elements on a web page are declared.
+ same was as elements on a web page are declared. This is done using
+ the Qt Markup Language which we will refer to by the abbreviation QML
+ for the remainder of the tutorial.
We will start by drawing a simple red rectangle with rounded corners.
@@ -123,14 +122,11 @@
\snippet declarative/tutorials/contacts/1_Drawing_and_Animation/1/RemoveButton.qml 0
- This is the simplest of QML components. It describes a rectangle with
+ This is one of the simplest of QML components. It describes a rectangle with
some simple properties. In QML all components start with a capital
- letter, and their properties with lower case letters. Properties
- can either be declared as XML attributes or as children of the
- component element.
+ letter, and their properties with lower case letters.
- The rectangle component is one of the more simple QML components. Apart
- from the properties all QML components share, it has the properties
+ Apart from the properties all QML components share, the \l{qml-rect}{Rect} component has the properties
\list
\o color - The background color of the rectangle
@@ -140,13 +136,9 @@
\o radius - The corner radius used to draw rounded rectangles.
\endlist
- \omit
- For more information on the Rect element, see: TODO
- \endomit
-
- There are also a number of properties all QML components share. To see
- a full description of the base QML item, see {QFxItem}. The rectangle
- drawn in the above code uses the properties;
+ There are also a number of properties all QML components shares, described
+ in the \l{qml-item}{Item} element reference documentation. The rectangle drawn in the
+ above code uses the properties;
\list
\o id - An identifier of the component
@@ -154,61 +146,61 @@
\o height - the height of the component when drawn
\endlist
- All items have properties to handle their position on the screen, size,
- clipping, rotation, scale and layout in regards to other elements. In
- the current example width and height refer to how large to draw the
- rectangle. The identifier allows other components to refer to the
- identified component.
-
- Another important property of a component is its children. All components
- have a list of children. When drawing, first any components earlier
- siblings are drawn, then the component, then any of the components children.
+ Currently we have described a rectangle with a width and height of 30 pixels, filled in with
+ the color red and with rounded corners using a radius of 5.
\section1 Layout
- The next step of the tutorial adds an image over the rectangle.
+ The next step of the tutorial adds an image over the rectangle. We
+ will do this by adding an \l{qml-image}{Image} component as a child of the
+ \l{qml-rect}{Rect} component. All QML components have a list of children which
+ are drawn in order after the parent component has been drawn.
+ By having the \l{qml-image}{Image}
+ component as a child of the \l{qml-rect}{Rect} component we ensure it is drawn
+ over the \l{qml-rect}{Rect} component. Children also are affected by the opacity
+ of the parent component and calculate their position in within the bounds of
+ the parent component.
\image declarative-removebutton-close.png
\snippet declarative/tutorials/contacts/1_Drawing_and_Animation/2/RemoveButton.qml 0
The trashIcon image is added as a child of the Rectangle. In this case
- the <children> tag isn't used because the default property of the
- Rect component is its children. Some elements don't often have children
- and use some other default component, when this is the case its possible
+ the children property isn't explicitly used because the default property
+ of the \l{qml-rect}{Rect} component is its children. Some elements often don't have children
+ and use some other default component. When this is the case its possible
to explicitly list the sub component as a child as follows:
\snippet declarative/tutorials/contacts/1_Drawing_and_Animation/2a/RemoveButton.qml 0
- The Image element allows loading an image file for display. The source
+ The \l{qml-image}{Image} element allows loading an image file for display. The source
specified is a URL, and in this case refers to a portable network graphics
file in a relative directory to where the QML file was loaded from.
Also new in this code is the use of anchors. In QML components can either
have their position and size specified explicitly using x, y, width
and height, or they can instead specify the size and position in relation
- to elements either parent or sibling elements. The Image component uses
+ to either parent or sibling elements. The \l{qml-image}{Image} component uses
a combination of both styles. It has a fixed size, but specifies its
position to align to the right of its parent and for its vertical center
- to align with the vertical center of its parent. The braces "{}" are
- used to indicate that the value is not a static value, but instead a
- binding to an expression. In this case it binds to the parent
- element, which is a special identifier that always refers to the
- parent component of a component. The removeButton identifier can
- be used interchangeably with parent in this case, however it must
- always be a parent or sibling. Because of this its most common to
- use the parent identifier as it makes later refactoring of code easier.
+ to align with the vertical center of its parent. Setting a property
+ by the identifier of a separate property binds them. This means
+ that if while running the example the position of the \l{qml-rect}{Rect} component's
+ vertical center changed, so to would the vertical center of
+ the \l{qml-image}{Image} component.
- Anchors are most useful when the size of items might change based on
- the component state or contents.
+ The parent value is a special identifier that always refers to the
+ parent component of a component.
- \omit
- See TODO for full list of anchor properties.
- \endomit
+ Anchors are most useful when the size of items might change based on
+ the component state or contents. However they are limited in that they
+ must always refer to a parent or sibling component. See
+ \l{anchor-layout}{Anchor-based Layout} for more information on using
+ anchors in QML.
At this point the initial state of the RemoveButton is complete. A small
- rounded rectangle with a trash icon. The component also needs a
- description of its open state:
+ rounded rectangle with a trash icon. Next we will design the open
+ state for the button.
\image declarative-removebutton-open.png
@@ -217,32 +209,31 @@
\snippet declarative/tutorials/contacts/1_Drawing_and_Animation/3/RemoveButton.qml 0
- The rectangle with is now wider by 200 pixels. Also the trashIcon has
- been replaced with the confirm state children. Normally we wouldn't
+ The rectangle width is now wider by 200 pixels. Also the trashIcon has
+ been replaced. Normally we wouldn't
remove the trashIcon when developing an alternate state of the RemoveButton,
however since this is a tutorial its been done so that its easier to
understand the alternate state we are aiming for and how it relates to
transitioning between states.
- We also introduce the Text element, which is used to display read only
- text. \omit see {Text} for more information on the text element \endomit
- Because we want text to fill the space between the icons, rather than
- a fixed with the left and right anchors are specified instead. This
+ We also introduce the \l{qml-text}{Text} element.
+ Left and Right anchors are specified in terms of the neighboring icons
+ because we want text to fill the space between the icons. This
means as the parent removeButton gets wider, so will the text component.
It also means that if we animate a width change on the removeButton,
- any bindings, that is the values specified by a braced expression such as
- "{parent.left}" will be evaluated and animated as well.
+ any bindings, that is the values specified by an expression such as
+ \c{parent.left} will be evaluated and animated as well.
\section1 Defining States
When designing a component with multiple states, it should be developed
- with the initial state and the changes that would be made specified
- as an additional state. Its not possible to add new children to an
- element when changing state, only changing the properties of existing
- children. This means that all possible child components should be included
+ in the initial state and the changes that would be made specified
+ as an additional state. Its not normally possible to add new children
+ to an element when changing state
+ This means that all possible child components should be included
in the initial state, and those that should not be visible in the initial
state should have their opacity set to zero. Thus
- for the RemoveButton we specify the starting size of the removeButton
+ for the RemoveButton we specify the starting size of the RemoveButton
and hide any items that should not initially be visible.
The code snippet below shows what the start of the duel state specification
@@ -305,9 +296,9 @@
all the children of the earlier sibling, should they overlap.
When a component has a signal, such as clicked, the action for the signal
- can be specified using on<SignalName>, as is done above. In this
+ can be specified using \c{onSignalName}, as is done above. In this
case when the clicked signal is emitted by the MouseRegion component,
- a function called toggle() is called. It might also have been written
+ a function called \c{toggle()} is called. It might also have been written
\code
onClicked: { removeButton.state='opened' }
@@ -317,14 +308,21 @@
mouse regions to use the same functionality, and also makes it
easier to specify complex behavior in response to a signal.
- The toggle() function is a new function specified as part of the remove
+ An alternative would be to explicitly state the connection:
+
+ \snippet declarative/tutorials/contacts/1_Drawing_and_Animation/4a/RemoveButton.qml mouse region
+
+ This will connect to the \c{clicked()} signal of the trashMouseRegion component
+ and execute the associated script.
+
+ The \c{toggle()} function is a new function specified as part of the remove
button element.
\snippet declarative/tutorials/contacts/1_Drawing_and_Animation/4/RemoveButton.qml script
Any QML component can have a set of resources specified. One of those
resources is any Script that might be needed. See the
- {QtScript Module}{QtScript Module} for more information on how to write
+ \l{qtscript}{QtScript Module} for more information on how to write
script code in Qt.
It is possible to refer to identified QML components
@@ -333,7 +331,7 @@
\section1 Animation
- Currently the RemoveButton is function, but snaps between our two states.
+ Currently the RemoveButton is functional, but snaps between our two states.
Fortunately making the transition between states smooth is very simple.
We only need one more bit of code at the end of our removeButton component.
@@ -368,6 +366,8 @@
editing a field of our contact. This ContactField in turn is intended
to be used in a contact editing control.
+ \image declarative-reuse-3.png
+
\section1 Loading QML Components
Reusing the RemoveButton itself is very simple. When parsing a QML file
@@ -386,50 +386,88 @@
\o The run directory + "/qml"
\o the directory of the QML code file
\o the directory of the QML code file + "/qml"
- \endlist.
+ \endlist
All the properties of the button are
accessible and can be overridden from defaults. The loaded component
can also refer to elements further up in the tree, so that code within
- RemoveButton.qml could refer to the contactField component. However only
- properties of the top level element in RemoveButton.qml are visible to
- the contact field. In order to allow contact field to modify how wide
- the remove button will be when opened we need to add a property to the
- remove button.
+ RemoveButton.qml could refer to the contactField component.
+ Only properties of the top level element in RemoveButton.qml are visible to
+ the contact field.
+
+ There are also two other ways to reuse components in QML. A component
+ can be reused from within the same QML file using Component and ComponentInstance
+ elements. The next code snippet produces three red rounded rectangles
+ within a large blue rectangle.
+
+ \image declarative-reuse-bluerect.png
+
+ \snippet declarative/tutorials/contacts/2_Reuse/1b/BlueRect.qml all
+
+ This can be useful when the component is not complex enough to justify its
+ own file. The third way to reuse components allows for delaying loading
+ of the QML until some later event. Each \l{qml-item}{Item} includes
+ a special child, qmlItem, which has its definition provided by the
+ contents of the qml property of its parent.
+
+ \snippet declarative/tutorials/contacts/2_Reuse/1a/ContactField.qml load
+
+ This last method is useful if the contents of a item need to change at
+ run time or if the initial complexity of the loaded QML needs to be
+ reduced in order to improve the time it takes to start the application. In
+ chapter three this method is used to improve performance of
+ scrolling through very large numbers of items.
+
+ Because of its simplicity, the first method is the recommended in most
+ cases and will be the focus of the remainder of this chapter.
\section1 Properties and Signals
+ The next task is to be able to control aspects of the RemoveButton from
+ the components that use it. In particular controlling how far it
+ expands and how it reacts when the user clicks on the confirm icon
+ of the remove button. When reusing a component in a separate QML file
+ only the attributes of the root element are visible. To allow controlling
+ attributes of child elements within an imported component we need to define
+ some properties and signals for the RemoveButton.
+
\snippet declarative/tutorials/contacts/2_Reuse/2/RemoveButton.qml define properties and signals
- These properties and signals are accessed from the contact field the same
- way standard system components are accessed.
+ The children of the remove button can use these properties and signals. The
+ opened state can now bind the expanded width to the expandedWidth property.
+
+ \snippet declarative/tutorials/contacts/2_Reuse/2/RemoveButton.qml use width
+
+ Also when the confirm icon is clicked, as well as toggling the state it will
+ emit the confirmed signal of the RemoveButton component.
+
+ \snippet declarative/tutorials/contacts/2_Reuse/2/RemoveButton.qml use signal
+
+ These properties and signals can also be accessed from the contact field the same
+ way standard system component properties and signals are accessed.
\snippet declarative/tutorials/contacts/2_Reuse/2/ContactField.qml use properties and signals
Now when the remove button is expanded, it will expand to the width of the
contact field. Also when the user confirms the remove action, the
- text section of the contact field will be cleared. When creating a
- component that does have children out of its own
- bounds its important to consider whether the item should be clipped,
- which is done above with \c{clip: true}.
+ text section of the contact field will be cleared.
\section1 States
Its also possible to access the state of included components. The FieldText
component we will use in this tutorial is also been written specifically
- for our contacts application, as was the RemoveButton component. In
+ for our contacts application. In
this case we want it to expand when editing. One way to do this would
be to anchor the field text component to the center of its parent and
then let its own width change push the remove button away, however that
would make it difficult to have the remove button also push the field
- text to the left when the remove button expands.
-
- So instead we will anchor the right edge of the field text to
- the left edge of the remove button and use a state change in the
- contact field itself to move the remove button and the field icon out of
+ text to the left when the remove button expands. Instead we will anchor
+ the right edge of the field text to the left edge of the remove button
+ and use a state change in the contact field itself to move the
+ remove button and the field icon out of
view.
- \snippet declarative/tutorials/contacts/2_Reuse/3/RemoveButton.qml all
+ \snippet declarative/tutorials/contacts/2_Reuse/3/ContactField.qml all
Apart from accessing the fieldText.state, the above code also uses the when
attribute of its own editingText state. This is an alternative to using
@@ -440,61 +478,63 @@
\snippet declarative/tutorials/contacts/2_Reuse/3/FieldText.qml behavior
- fieldText is the enclosing component and textEdit is a TextEdit element
+ \c{fieldText} is the enclosing component and \c{textEdit} is a TextEdit element
provided by Qt. In the QML code above, the opacity of the textLabel is
- only 1 if there is text for the textEdit is empty. This is a form of
+ only 1 if the text for the textEdit is empty. This is a form of
short cut to using states for an element, useful if only one property
is changing as it is for the textLabel. To animate a property change is
similar to animating a state change. Using the Behavior element we can
specify how the property changes if it does change state, allowing for
a smooth transition.
- The fieldText element also handles changes to the text using the
- onValueChanged attribute when specifying properties.
-
- \snippet declarative/tutorials/contacts/2_Reuse/3/FieldText.qml value change
-
- Because the user needs to be able to edit text in the text edit, it
- shouldn't be simply bound to the text property of the FieldText component.
- However if a component using the FieldText component sets the text
- property of the FieldText component it should in turn set the text
- of the text edit.
-
\section1 Key and Mouse Focus
- Unlike in Qt setting focus to true on a component does not always mean
+ Setting focus to true on a component does not always mean
that the component has focus. This is due to the declarative nature
of QML, and can be affected by multiple components both indicating
focus to be true. At the time of writing this tutorial both key and mouse
focus handling are still being improved. Hence we will only lightly cover
the topic.
- Normally in QML this is handled by FocusRealm components. A focus realm
- is a sort of cut off point for determining focus. If a FocusRealm does
- not have focus then any children of it won't be able to get focus even
- if they do set focus to true. If your component has multiple child
- components that could gain focus ensure that they are guarded by FocusRealm
- component, and add code to handle which focus realms have focus
- at that level. The alternative and approach done at this stage in
- the tutorial is to only have one component set focus to true at a time.
+ For an item to have key focus in QML it is required that:
+
+ \list
+ \o If there is a FocusRealm ancestor of the component that it has focus as well.
+ \o That it is the most recent component within the focus realms descendent's
+ to receive focus
+ \endlist
+
+ The read-only property activeFocus can be used to determine whether a
+ component will receive key input. Any un-handled keys will be passed to
+ the components parent, which in turn will pass keys it doesn't handle up to its
+ own ancestors.
+
+ Some components such as ListView components are also FocusRealm components, as they
+ handle focus among the child list items.
+
+ At this stage of the tutorial it is sufficient to use the setting of 'focus'
+ as we only have a list of line edits and only one should be active at any given time.
Currently if multiple contact fields were put into our contact editor,
any of the FieldText components could be clicked and opened, and
any of the RemoveButton components could be clicked and opened, all
- at the same time. We would like this behavior to be some what modal
- instead, encouraging the user to either accept or cancel the current
- action before moving onto a new action.
+ at the same time. This leads to situations where the users actions
+ are ambiguous
+
+ \image declarative-reuse-focus.png
- In the tutorial we do this with a property of our top level component
- to handle whether we are in this state or not.
+ To counteract this we will add a property of the root element to indicate
+ when an element has 'grabbed' mouse interaction, preventing other
+ clickable elements from reacting.
\snippet declarative/tutorials/contacts/2_Reuse/4/Contact.qml grab property
- And in the code where we want to check or avoid allowing mouse interaction.
+ The code that we want to disable then simply needs to check this property before
+ acting.
\snippet declarative/tutorials/contacts/2_Reuse/4/RemoveButton.qml grab
- Handling Key and Mouse focus in QML is quite likely to change before
+ \note Handling Key and Mouse focus in QML is quite likely to change before
the Qt 4.6 release.
*/
@@ -618,13 +658,13 @@
Its important then to try and minimize the complexity of the delegate. This
can be done by delaying the loading of the component. By using the qml property
- of the Item component, we can delay building the Contact.qml item until the user
+ of the \l{qml-item}{Item} component, we can delay building the Contact.qml item until the user
attempts to open the list.
\snippet declarative/tutorials/contacts/3_Collections/3/ContactView.qml setting qml
Each item has a qml property that represents the filename for the contents of
- a special qmlItem child of the Item. By setting the qml property of the Details
+ a special qmlItem child of the \l{qml-item}{Item}. By setting the qml property of the Details
component on clicking the mouse region, the more complex component isn't loaded
until needed. The down side about this though is the properties of Contact
cannot be set until the item is loaded. This requires using the Bind