diff options
Diffstat (limited to 'doc/src/declarative')
22 files changed, 871 insertions, 333 deletions
diff --git a/doc/src/declarative/advtutorial.qdoc b/doc/src/declarative/advtutorial.qdoc index afedb44..1341bbb 100644 --- a/doc/src/declarative/advtutorial.qdoc +++ b/doc/src/declarative/advtutorial.qdoc @@ -164,14 +164,22 @@ The \c createBlock() function creates a block from the \c Block.qml file and moves the new block to its position on the game canvas. This involves several steps: \list -\o \l {QML:Qt::createComponent()}{Qt.createComponent()} is called to generate an element from \c Block.qml. - If the component is ready, we can call \c createObject() to create an instance of the \c Block item. -\o If \c createObject() returned null (i.e. if there was an error while - loading the object), print the error information. -\o Place the block in its position on the board and set its width and height. - Also, store it in the blocks array for future reference. -\o Finally, print error information to the console if the component could not be - loaded for some reason (for example, if the file is missing). + +\o \l {QML:Qt::createComponent()}{Qt.createComponent()} is called to + generate an element from \c Block.qml. If the component is ready, + we can call \c createObject() to create an instance of the \c Block + item. + +\o If \c createObject() returned null (i.e. if there was an error + while loading the object), print the error information. + +\o Place the block in its position on the board and set its width and + height. Also, store it in the blocks array for future reference. + +\o Finally, print error information to the console if the component + could not be loaded for some reason (for example, if the file is + missing). + \endlist diff --git a/doc/src/declarative/animation.qdoc b/doc/src/declarative/animation.qdoc index c5333df..401cf16 100644 --- a/doc/src/declarative/animation.qdoc +++ b/doc/src/declarative/animation.qdoc @@ -67,7 +67,9 @@ A property animation can also be specified as a resource that is manipulated fro \snippet doc/src/snippets/declarative/animation.qml property-anim-3 As can be seen, when an animation is used like this (as opposed to as a value source) you will need -to explicitly set the \c target and \c property to animate. +to explicitly set the \c target and \c property to animate. This also the only case where +an animation needs to be started explictly by either setting the \c running property to +true or calling the \c start() method. Animations can be joined into a group using SequentialAnimation and ParallelAnimation. diff --git a/doc/src/declarative/dynamicobjects.qdoc b/doc/src/declarative/dynamicobjects.qdoc index a5e53a9..997f601 100644 --- a/doc/src/declarative/dynamicobjects.qdoc +++ b/doc/src/declarative/dynamicobjects.qdoc @@ -39,31 +39,35 @@ QML also supports the dynamic creation of objects from within JavaScript code. This is useful if the existing QML elements do not fit the needs of your application, and there are no C++ components involved. -See the {declarative/toys/dynamicscene}{Dynamic Scene example} for a demonstration +See the \l {declarative/toys/dynamicscene}{Dynamic Scene example} for a demonstration of the concepts discussed on this page. \section1 Creating Objects Dynamically There are two ways to create objects dynamically from JavaScript. You can either call -\l {QML:Qt::createComponent()}{Qt.createComponent()} to create -a component which instantiates items, or use \l{QML:Qt::createQmlObject()}{Qt.createQmlObject()} +\l {QML:Qt::createComponent()}{Qt.createComponent()} to dynamically create +a \l Component object, or use \l{QML:Qt::createQmlObject()}{Qt.createQmlObject()} to create an item from a string of QML. -Creating a component is better if you have a predefined -item, and you want to create dynamic instances of that item; creating an item from -a string of QML is useful when the item QML itself is generated at runtime. +Creating a component is better if you have an existing component defined in a \c .qml +file, and you want to dynamically create instances of that component. Otherwise, +creating an item from a string of QML is useful when the item QML itself is generated +at runtime. -If you have a component specified in a QML file, you can dynamically load it with -the \l {QML:Qt::createComponent()}{Qt.createComponent()} function on the \l{QML Global Object}. -This function takes the URL of the QML file as its only argument and returns -a component object which can be used to create and load that QML file. -Once you have a component you can use its \l {Component::createObject()}{createObject()} method to create an instance of +\section2 Creating a Component dynamically + +To dynamically load a component defined in a QML file, call the +\l {QML:Qt::createComponent()}{Qt.createComponent()} function on the \l{QML Global Object}. +This function takes the URL of the QML file as its only argument and creates +a \l Component object from this URL. + +Once you have a \l Component, you can call its \l {Component::createObject()}{createObject()} method to create an instance of the component. This function takes exactly one argument, which is the parent for the new item. Since graphical items will not appear on the scene without a parent, it is recommended that you set the parent this way. However, if you wish to set -the parent later you can safely pass null to this function. +the parent later you can safely pass \c null to this function. -Here is an example. Here is a \c Sprite.qml, which defines a simple QML component: +Here is an example. First there is \c Sprite.qml, which defines a simple QML component: \snippet doc/src/snippets/declarative/Sprite.qml 0 @@ -72,35 +76,48 @@ that will create \c Sprite objects: \snippet doc/src/snippets/declarative/createComponent.qml 0 -Here is \c componentCreation.js. Remember that QML files that might be loaded -over the network cannot be expected to be ready immediately: +Here is \c componentCreation.js. Notice it checks whether the component \l{Component::status}{status} is +\c Component.Ready before calling \l {Component::createObject()}{createObject()} +in case the QML file is loaded over a network and thus is not ready immediately. -\snippet doc/src/snippets/declarative/componentCreation.js 0 +\snippet doc/src/snippets/declarative/componentCreation.js vars +\codeline +\snippet doc/src/snippets/declarative/componentCreation.js func +\snippet doc/src/snippets/declarative/componentCreation.js remote +\snippet doc/src/snippets/declarative/componentCreation.js func-end \codeline -\snippet doc/src/snippets/declarative/componentCreation.js 1 +\snippet doc/src/snippets/declarative/componentCreation.js finishCreation -If you are certain the files will be local, you could simplify to: +If you are certain the QML file to be loaded is a local file, you could omit the \c finishCreation() +function and call \l {Component::createObject()}{createObject()} immediately: -\snippet doc/src/snippets/declarative/componentCreation.js 2 +\snippet doc/src/snippets/declarative/componentCreation.js func +\snippet doc/src/snippets/declarative/componentCreation.js local +\snippet doc/src/snippets/declarative/componentCreation.js func-end -Notice that once a \c Sprite object is created, its parent is set to \c appWindow (defined -in \c main.qml). After creating an item, you must set its parent to an item within the scene. -Otherwise your dynamically created item will not appear in the scene. +Notice in both instances, \l {Component::createObject()}{createObject()} is called with +\c appWindow passed as an argument so that the created object will become a child of the +\c appWindow item in \c main.qml. Otherwise, the new item will not appear in the scene. When using files with relative paths, the path should be relative to the file where \l {QML:Qt::createComponent()}{Qt.createComponent()} is executed. -If the QML component does not exist until runtime, you can create a QML item from + +\section2 Creating an object from a string of QML + +If the QML is not defined until runtime, you can create a QML item from a string of QML using the \l{QML:Qt::createQmlObject()}{Qt.createQmlObject()} function, as in the following example: \snippet doc/src/snippets/declarative/createQmlObject.qml 0 The first argument is the string of QML to create. Just like in a new file, you will need to -import any types you wish to use. For importing files with relative paths, the path should -be relative to the file where the item in the second argument is defined. Remember to set the parent after -creating the item. The second argument is another item in the scene, and the new item is created -in the same QML Context as this item. The third argument is the file path associated with this -item, which is used for error reporting. +import any types you wish to use. The second argument is the parent item for the new item; +this should be an existing item in the scene. The third argument is the file path to associate +with the new item; this is used for error reporting. + +If the string of QML imports files using relative paths, the path should be relative +to the file in which the parent item (the second argument to the method) is defined. + \section1 Maintaining Dynamically Created Objects @@ -114,9 +131,9 @@ The actual creation context depends on how an item is created: \o If \l {QML:Qt::createComponent()}{Qt.createComponent()} is used, the creation context is the QDeclarativeContext in which this method is called \o If \l{QML:Qt::createQmlObject()}{Qt.createQmlObject()} - if called, it is the context of the item used as the second argument to this method + if called, the creation context is the context of the parent item passed to this method \o If a \c {Component{}} item is defined and \l {Component::createObject()}{createObject()} - is called on that item, it is the context in which the \c Component is defined + is called on that item, the creation context is the context in which the \c Component is defined \endlist Also, note that while dynamically created objects may be used the same as other objects, they @@ -131,17 +148,47 @@ lots of dynamically created items, however, you may receive a worthwhile performance benefit if unused items are deleted. Note that you should never manually delete items that were dynamically created -by QML elements (such as \l Loader). Also, you should generally avoid deleting +by QML elements (such as \l Loader and \l Repeater). Also, you should avoid deleting items that you did not dynamically create yourself. Items can be deleted using the \c destroy() method. This method has an optional argument (which defaults to 0) that specifies the approximate delay in milliseconds -before the object is to be destroyed. This allows you to wait until the completion of -an animation or transition. An example: +before the object is to be destroyed. + +Here is an example. The \c application.qml creates five instances of the \c SelfDestroyingRect.qml +component. Each instance runs a NumberAnimation, and when the animation has finished, calls +\c destroy() on its root item to destroy itself: + +\table +\row +\o \c application.qml +\o \c SelfDestroyingRect.qml -\snippet doc/src/snippets/declarative/dynamicObjects.qml 0 +\row +\o \snippet doc/src/snippets/declarative/dynamicObjects-destroy.qml 0 +\o \snippet doc/src/snippets/declarative/SelfDestroyingRect.qml 0 + +\endtable + +Alternatively, the \c application.qml could have destroyed the created object +by calling \c object.destroy(). + +Notice that if a \c SelfDestroyingRect instance was created statically like this: + +\qml +Item { + SelfDestroyingRect { ... } +} +\endqml + +This would result in an error, since items can only be dynamically +destroyed if they were dynamically created. + +Objects created with \l{QML:Qt::createQmlObject()}{Qt.createQmlObject()} +can similarly be destroyed using \c destroy(): + +\snippet doc/src/snippets/declarative/createQmlObject.qml 0 +\snippet doc/src/snippets/declarative/createQmlObject.qml destroy -Here, \c Rectangle objects are destroyed one second after they are created, which is long -enough for the \c NumberAnimation to be played before the object is destroyed. */ diff --git a/doc/src/declarative/elements.qdoc b/doc/src/declarative/elements.qdoc index 0edd242..c2930b3 100644 --- a/doc/src/declarative/elements.qdoc +++ b/doc/src/declarative/elements.qdoc @@ -113,7 +113,7 @@ The following table lists the QML elements provided by the \l {QtDeclarative}{Qt \row \o \l {Connections} \o Explicitly connects signals and signal handlers \row \o \l {Component} \o Encapsulate QML items as a component \row \o \l {Timer} \o Provides timed triggers -\row \o \l {QtObject} \o Basic element containing only the objectName property +\row \o \l {QML:QtObject} {QtObject} \o Basic element containing only the objectName property \row \o \l {WorkerScript} \o Enables the use of threads in QML \row \o \l {Loader} \o Controls the loading of items or components \row \o \l {Repeater} \o Uses a model to create multiples of components diff --git a/doc/src/declarative/examples.qdoc b/doc/src/declarative/examples.qdoc index 8a24228..9929cfe 100644 --- a/doc/src/declarative/examples.qdoc +++ b/doc/src/declarative/examples.qdoc @@ -175,6 +175,7 @@ The examples can be found in Qt's \c examples/declarative directory. \list \o \l{declarative/modelviews/gridview}{GridView} \o \l{declarative/modelviews/listview}{ListView} +\o \l{declarative/modelviews/pathview}{PathView} \o \l{declarative/modelviews/package}{Package} \o \l{declarative/modelviews/parallax}{Parallax} \o \l{declarative/modelviews/visualitemmodel}{VisualItemModel} @@ -202,6 +203,11 @@ The examples can be found in Qt's \c examples/declarative directory. \o \l{declarative/threading/workerscript}{WorkerScript} \endlist +\section2 Screen orientation +\list +\o \l{declarative/screenorientation}{Example} +\endlist + \section2 SQL Local Storage \list \o \l{declarative/sqllocalstorage}{Example} diff --git a/doc/src/declarative/extending-tutorial.qdoc b/doc/src/declarative/extending-tutorial.qdoc index 2cf00b9..d128d0f 100644 --- a/doc/src/declarative/extending-tutorial.qdoc +++ b/doc/src/declarative/extending-tutorial.qdoc @@ -48,8 +48,9 @@ Tutorial chapters: \o \l{declarative/tutorials/extending/chapter2-methods}{Connecting to C++ Methods and Signals} \o \l{declarative/tutorials/extending/chapter3-bindings}{Adding Property Bindings} \o \l{declarative/tutorials/extending/chapter4-customPropertyTypes}{Using Custom Property Types} -\o \l{declarative/tutorials/extending/chapter5-plugins}{Writing an Extension Plugin} -\o \l{qml-extending-tutorial6.html}{In Summary} +\o \l{declarative/tutorials/extending/chapter5-listproperties}{Using List Property Types} +\o \l{declarative/tutorials/extending/chapter6-plugins}{Writing an Extension Plugin} +\o \l{qml-extending-tutorial7.html}{In Summary} \endlist */ @@ -59,61 +60,94 @@ Tutorial chapters: \example declarative/tutorials/extending/chapter1-basics -Let's create a new QML type called "Musician" that has two properties: a name -and an instrument. We will make it available in a \l {Modules}{module} called "Music", with +A common task when extending QML is to provide a new QML type that supports some + custom functionality beyond what is provided by the built-in \l {QML Elements}. +For example, this could be done to implement particular data models, or provide +elements with custom painting and drawing capabilities, or access system features +like network programming that are not accessible through built-in QML features. + +In this tutorial, we will show how to use the C++ classes in the QtDeclarative +module to extend QML. The end result will be a simple Pie Chart display implemented by +several custom QML types connected together through QML features like bindings and +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. -We want this \c Musician type to be usable from QML like this: + +We want this \c PieChart type to be usable from QML like this: \code - import Music 1.0 + import Charts 1.0 - Musician { - name: "Reddy the Rocker" - instrument: "Guitar" + PieChart { + width: 100; height: 100 + name: "A simple pie chart" + color: "red" } \endcode -To do this, we need a C++ class that encapsulates this \c Musician type and its two -properties. Since QML relies heavily on Qt's \l{Meta-Object System}{meta object system}, +To do this, we need a C++ class that encapsulates this \c PieChart type and its two +properties. Since QML makes extensive use of Qt's \l{Meta-Object System}{meta object system}, this new class must: \list -\o inherit from QObject -\o declare its properties using the Q_PROPERTY() macro +\o Inherit from QObject +\o Declare its properties using the Q_PROPERTY macro \endlist -Here is our \c Musician class, defined in \c musician.h: +Here is our \c PieChart class, defined in \c piechart.h: -\snippet declarative/tutorials/extending/chapter1-basics/musician.h 0 +\snippet declarative/tutorials/extending/chapter1-basics/piechart.h 0 -It defines the two properties, \c name and \c instrument, with the Q_PROPERTY() macro. -The class implementation in \c musician.cpp simply sets and returns the \c m_name and -\c m_instrument values as appropriate. +The class inherits from QDeclarativeItem because we want to override +QDeclarativeItem::paint() in order to draw. If the class just represented some +data type and was not an item that actually needed to be displayed, it could simply inherit +from QObject. Or, if we want to extend the functionality of an existing QObject-based +class, it could inherit from that class instead. -Our QML file, \c app.qml, creates a \c Musician item and display the musician's details +The \c PieChart class defines the two properties, \c name and \c color, with the Q_PROPERTY macro, +and overrides QDeclarativeItem::paint(). The class implementation in \c piechart.cpp +simply sets and returns the \c m_name and \c m_color values as appropriate, and +implements \c paint() to draw a simple pie chart. It also turns off the +QGraphicsItem::ItemHasNoContents flag to enable painting: + +\snippet declarative/tutorials/extending/chapter1-basics/piechart.cpp 0 +\dots 0 +\snippet declarative/tutorials/extending/chapter1-basics/piechart.cpp 1 + +Now that we have defined the \c PieChart type, we will use it from QML. The \c app.qml +file creates a \c PieChart item and display the pie chart's details using a standard QML \l Text item: \snippet declarative/tutorials/extending/chapter1-basics/app.qml 0 +Notice that although the color is specified as a string in QML, it is automatically +converted to a QColor object for the PieChart \c color property. Automatic conversions are +provided for various other \l {QML Basic Types}{basic types}; for example, a string +like "640x480" can be automatically converted to a QSize value. + We'll also create a C++ application that uses a QDeclarativeView to run and -display \c app.qml. The application must register the \c Musician type +display \c app.qml. The application must register the \c PieChart type using the qmlRegisterType() function, to allow it to be used from QML. If -you don't register the type, \c app.qml won't be able to create a \c Musician. +you don't register the type, \c app.qml won't be able to create a \c PieChart. Here is the application \c main.cpp: \snippet declarative/tutorials/extending/chapter1-basics/main.cpp 0 -This call to qmlRegisterType() registers the \c Musician type as a type called "Musician", in a module named "Music", +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. Lastly, we write a \c .pro project file that includes the files and the \c declarative library: \quotefile declarative/tutorials/extending/chapter1-basics/chapter1-basics.pro -Now we can build and run the application. Try it yourself with the code in Qt's \c examples/tutorials/extending/chapter1-basics directory. +Now we can build and run the application: -\example declarative/tutorials/extending/chapter1-basics +\image extending-tutorial-chapter1.png + +Try it yourself with the code in Qt's \c examples/tutorials/extending/chapter1-basics directory. At the moment, the \c app.qml is run from within a C++ application. This may seem odd if you're used to running QML files with the \l {QML Viewer}. @@ -128,39 +162,40 @@ Later on, we'll show how to create a plugin so that you can run \c app.qml using \example declarative/tutorials/extending/chapter2-methods -Suppose we want \c Musician to have a "perform" method that prints a message -to the console and then emits a "performanceEnded" signal. -Other elements would be able to call \c perform() and receive -\c performanceEnded() signals like this: +Suppose we want \c PieChart to have a "clearChart()" method that erases the +chart and then emits a "chartCleared" signal. Our \c app.qml would be able +to call \c clearChart() and receive \c chartCleared() signals like this: \snippet declarative/tutorials/extending/chapter2-methods/app.qml 0 -To do this, we add a \c perform() method and a \c performanceEnded() signal +\image extending-tutorial-chapter2.png + +To do this, we add a \c clearChart() method and a \c chartCleared() signal to our C++ class: -\snippet declarative/tutorials/extending/chapter2-methods/musician.h 0 +\snippet declarative/tutorials/extending/chapter2-methods/piechart.h 0 \dots -\snippet declarative/tutorials/extending/chapter2-methods/musician.h 1 +\snippet declarative/tutorials/extending/chapter2-methods/piechart.h 1 \dots -\snippet declarative/tutorials/extending/chapter2-methods/musician.h 2 +\snippet declarative/tutorials/extending/chapter2-methods/piechart.h 2 \dots -\snippet declarative/tutorials/extending/chapter2-methods/musician.h 3 +\snippet declarative/tutorials/extending/chapter2-methods/piechart.h 3 -The use of Q_INVOKABLE makes the \c perform() method available to the +The use of Q_INVOKABLE makes the \c clearChart() method available to the Qt Meta-Object system, and in turn, to QML. Note that it could have been declared as as a Qt slot instead of using Q_INVOKABLE, as slots are also callable from QML. Both of these approaches are valid. -The \c perform() method simply prints a message to the console and -then emits \c performanceEnded(): +The \c clearChart() method simply changes the color to Qt::transparent, +repaints the chart, then emits the \c chartCleared() signal: -\snippet declarative/tutorials/extending/chapter2-methods/musician.cpp 0 +\snippet declarative/tutorials/extending/chapter2-methods/piechart.cpp 0 -Now when we run the application and click the window, the application outputs: +Now when we run the application and click the window, the pie chart +disappears, and the application outputs: \code - "Reddy the Rocker" is playing the "Guitar" - The performance has now ended + The chart has been cleared \endcode Try out the example yourself with the updated code in Qt's \c examples/tutorials/extending/chapter2-methods directory. @@ -174,45 +209,49 @@ Try out the example yourself with the updated code in Qt's \c examples/tutorials Property bindings is a powerful feature of QML that allows values of different elements to be synchronized automatically. It uses signals to notify and update -other elements' values when property values change. +other elements' values when property values are changed. -Let's enable property bindings for the \c instrument property. That means +Let's enable property bindings for the \c color property. That means if we have code like this: \snippet declarative/tutorials/extending/chapter3-bindings/app.qml 0 -The "instrument: reddy.instrument" statement binds the \c instrument value of -\c craig to the \c instrument of \c reddy. -Whenever \c reddy's \c instrument value changes, \c craig's \c instrument value -updates to the same value. When the window is clicked, the application outputs: +\image extending-tutorial-chapter3.png -\code - "Reddy the Rocker" is playing the "Guitar" - "Craig the Copycat" is playing the "Guitar" - "Reddy the Rocker" is playing the "Drums" - "Craig the Copycat" is playing the "Drums" -\endcode +The "color: chartA.color" statement binds the \c color value of +\c chartB to the \c color of \c chartA. +Whenever \c chartA's \c color value changes, \c chartB's \c color value +updates to the same value. When the window is clicked, the \c onClicked +handler in the MouseArea changes the color of \c chartA, thereby changing +both charts to the color blue. -It's easy to enable property binding for the \c instrument property. -We add a \l{Qt's Property System}{NOTIFY} feature to its Q_PROPERTY() declaration to indicate that a "instrumentChanged" signal +It's easy to enable property binding for the \c color property. +We add a \l{Qt's Property System}{NOTIFY} feature to its Q_PROPERTY() declaration to indicate that a "colorChanged" signal is emitted whenever the value changes. -\snippet declarative/tutorials/extending/chapter3-bindings/musician.h 0 +\snippet declarative/tutorials/extending/chapter3-bindings/piechart.h 0 \dots -\snippet declarative/tutorials/extending/chapter3-bindings/musician.h 1 +\snippet declarative/tutorials/extending/chapter3-bindings/piechart.h 1 \dots -\snippet declarative/tutorials/extending/chapter3-bindings/musician.h 2 +\snippet declarative/tutorials/extending/chapter3-bindings/piechart.h 2 \dots -\snippet declarative/tutorials/extending/chapter3-bindings/musician.h 3 +\snippet declarative/tutorials/extending/chapter3-bindings/piechart.h 3 -Then, we emit this signal in \c setInstrument(): +Then, we emit this signal in \c setPieSlice(): -\snippet declarative/tutorials/extending/chapter3-bindings/musician.cpp 0 +\snippet declarative/tutorials/extending/chapter3-bindings/piechart.cpp 0 -It's important for \c setInstrument() to check that the instrument value has actually changed -before emitting \c instrumentChanged(). This ensures the signal is not emitted unnecessarily and +It's important for \c setColor() to check that the color value has actually changed +before emitting \c colorChanged(). This ensures the signal is not emitted unnecessarily and also prevents loops when other elements respond to the value change. +The use of bindings is essential to QML. You should always add NOTIFY +signals for properties if they are able to be implemented, so that your +properties can be used in bindings. Properties that cannot be bound cannot be +automatically updated and cannot be used as flexibly in QML. Also, since +bindings are invoked so often and relied upon in QML usage, users of your +custom QML types may see unexpected behavior if bindings are not implemented. + */ /*! @@ -220,21 +259,35 @@ also prevents loops when other elements respond to the value change. \example declarative/tutorials/extending/chapter4-customPropertyTypes -The \c Musician type currently has two properties that are both strings. -It could have all sorts of other properties. For example, we could add an -integer-type property to store the age of each musician: +The \c PieChart type currently has a string-type property and a color-type property. +It could have many other types of properties. For example, it could have an +enum-type property to store a display mode for each chart: \code - class Musician : public QObject + // C++ + class PieChart : public QDeclarativeItem { + Q_ENUMS(DisplayMode) + Q_PROPERTY(DisplayMode displayMode READ displayMode WRITE setDisplayMode) ... - Q_PROPERTY(int age READ age WRITE setAge) + public: - ... - int age() const; - void setAge(int age); + enum DisplayMode { + MultiLevel, + Exploded, + ThreeDimensional + }; + + void setDisplayMode(DisplayMode mode); + DisplayMode displayMode() const; ... }; + + // QML + PieChart { + ... + displayMode: PieChart.Exploded + } \endcode We can also use various other property types. QML has built-in support for the following @@ -257,31 +310,39 @@ types: If we want to create a property whose type is not supported by QML by default, we need to register the type with QML. -For example, let's change the type of the \c instrument property from a string to a -new type called "Instrument". Instead of assigning a string value to \c instrument, -we assign an \c Instrument value: +For example, let's replace the use of the \c property with a type called +"PieSlice" that has a \c color property. Instead of assigning a color, +we assign an \c PieSlice value which itself contains a \c color: \snippet declarative/tutorials/extending/chapter4-customPropertyTypes/app.qml 0 -Like \c Musician, this new \c Instrument type has to inherit from QObject and declare +Like \c PieChart, this new \c PieSlice type inherits from QDeclarativeItem and declares its properties with Q_PROPERTY(): -\snippet declarative/tutorials/extending/chapter4-customPropertyTypes/instrument.h 0 +\snippet declarative/tutorials/extending/chapter4-customPropertyTypes/pieslice.h 0 -To use it from \c Musician, we modify the \c instrument property declaration +To use it in \c PieChart, we modify the \c color property declaration and associated method signatures: -\snippet declarative/tutorials/extending/chapter4-customPropertyTypes/musician.h 0 +\snippet declarative/tutorials/extending/chapter4-customPropertyTypes/piechart.h 0 \dots -\snippet declarative/tutorials/extending/chapter4-customPropertyTypes/musician.h 1 +\snippet declarative/tutorials/extending/chapter4-customPropertyTypes/piechart.h 1 \dots -\snippet declarative/tutorials/extending/chapter4-customPropertyTypes/musician.h 2 +\snippet declarative/tutorials/extending/chapter4-customPropertyTypes/piechart.h 2 \dots -\snippet declarative/tutorials/extending/chapter4-customPropertyTypes/musician.h 3 +\snippet declarative/tutorials/extending/chapter4-customPropertyTypes/piechart.h 3 + +There is one thing to be aware of when implementing \c setPieSlice(). The \c PieSlice +is a visual item, so it must be set as a child of the \c PieChart using +QDeclarativeItem::setParentItem() so that the \c PieChart knows to paint this child +item when its contents are drawn: -Like the \c Musician type, the \c Instrument type has to be registered -using qmlRegisterType() to be used from QML. As with \c Musician, we'll add the -type to the "Music" module, version 1.0: +\snippet declarative/tutorials/extending/chapter4-customPropertyTypes/piechart.cpp 0 + + +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: \snippet declarative/tutorials/extending/chapter4-customPropertyTypes/main.cpp 0 \dots @@ -293,15 +354,65 @@ Try it out with the code in Qt's \c examples/tutorials/extending/chapter4-custom */ + +/*! +\title Chapter 5: Using List Property Types + +\example declarative/tutorials/extending/chapter5-listproperties + +Right now, a \c PieChart can only have one \c PieSlice. Ideally a chart would +have multiple slices, with different colors and sizes. To do this, we could +have a \c slices property that accepts a list of \c PieSlice items: + +\snippet declarative/tutorials/extending/chapter5-listproperties/app.qml 0 + +\image extending-tutorial-chapter5.png + +To do this, we replace the \c pieSlice property in \c PieChart with a \c slices property, +declared as a QDeclarativeListProperty type. The QDeclarativeListProperty class enables the +creation of list properties in QML extensions. We replace the \c pieSlice() +function with a \c slices() function that returns a list of slices, and add +an internal \c append_slice() function (discussed below). We also use a QList to +store the internal list of slices as \c m_slices: + +\snippet declarative/tutorials/extending/chapter5-listproperties/piechart.h 0 +\dots +\snippet declarative/tutorials/extending/chapter5-listproperties/piechart.h 1 +\dots +\snippet declarative/tutorials/extending/chapter5-listproperties/piechart.h 2 + +Although the \c slices property does not have an associated \c WRITE function, +it is still modifiable because of the way QDeclarativeListProperty works. +In the \c PieChart implementation, we implement \c PieChart::slices() to +return a QDeclarativeListProperty value and indicate that the internal +\c PieChart::append_slice() function is to be called whenever a request is made from QML +to add items to the list: + +\snippet declarative/tutorials/extending/chapter5-listproperties/piechart.cpp 0 + +The \c append_slice() function simply sets the parent item as before, +and adds the new item to the \c m_slices list. As you can see, the append function for a +QDeclarativeListProperty is called with two arguments: the list property, and +the item that is to be appended. + +The \c PieSlice class has also been modified to include \c fromAngle and \c angleSpan +properties and to draw the slice according to these values. This is a straightforward +modification if you have read the previous pages in this tutorial, so the code is not shown here. + +The complete code can be seen in the updated \c examples/tutorials/extending/chapter5-listproperties directory. + +*/ + + /*! -\title Chapter 5: Writing an Extension Plugin +\title Chapter 6: Writing an Extension Plugin -\example declarative/tutorials/extending/chapter5-plugins +\example declarative/tutorials/extending/chapter6-plugins -Currently the \c Musician and \c Instrument types are used by \c app.qml, +Currently the \c PieChart and \c PieSlice types are used by \c app.qml, which is displayed using a QDeclarativeView 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 means we could load \c app.qml using the \l {QML Viewer} +to the QML engine. This allows \c app.qml to be loaded with the \l {QML Viewer} (or some other QML \l{Qt Declarative UI Runtime}{runtime} application) instead of writing a \c main.cpp file and loading our own C++ application. @@ -310,31 +421,31 @@ To create a plugin library, we need: \list \o A plugin class that registers our QML types \o A project file that describes the plugin -\o A "qmldir" file that tells the QML engine to load the plugin +\o A \l{Writing a qmldir file}{qmldir} file that tells the QML engine to load the plugin \endlist -First, we create a plugin class named \c MusicPlugin. It subclasses QDeclarativeExtensionPlugin +First, we create a plugin class named \c ChartsPlugin. It subclasses QDeclarativeExtensionPlugin and registers our QML types in the inherited \l{QDeclarativeExtensionPlugin::}{registerTypes()} method. It also calls Q_EXPORT_PLUGIN2 for Qt's \l{How to Create Qt Plugins}{plugin system}. -Here is the \c MusicPlugin definition in \c musicplugin.h: +Here is the \c ChartsPlugin definition in \c chartsplugin.h: -\snippet declarative/tutorials/extending/chapter5-plugins/musicplugin.h 0 +\snippet declarative/tutorials/extending/chapter6-plugins/chartsplugin.h 0 -And its implementation in \c musicplugin.cpp: +And its implementation in \c chartsplugin.cpp: -\snippet declarative/tutorials/extending/chapter5-plugins/musicplugin.cpp 0 +\snippet declarative/tutorials/extending/chapter6-plugins/chartsplugin.cpp 0 Then, we write a \c .pro project file that defines the project as a plugin library and specifies with DESTDIR that library files should be built into a "lib" subdirectory: -\quotefile declarative/tutorials/extending/chapter5-plugins/chapter5-plugins.pro +\quotefile declarative/tutorials/extending/chapter6-plugins/chapter6-plugins.pro -Finally, we add a \c qmldir file that is automatically parsed by the QML engine. -Here, we specify that a plugin named "chapter5-plugin" (the name +Finally, we add a \l{Writing a qmldir file}{qmldir} file that is automatically 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 declarative/tutorials/extending/chapter5-plugins/qmldir +\quotefile declarative/tutorials/extending/chapter6-plugins/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 in the \l {QML Viewer}: @@ -345,15 +456,16 @@ the project and then load the QML file in the \l {QML Viewer}: (On Mac OS X, you can launch the "QMLViewer" application instead.) -Notice the "import Music 1.0" statement has disappeared from \c app.qml. This is +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 Musician.qml and Instrument.qml files inside the project directory, which could both +having PieChart.qml and PieSlice.qml files inside the project directory, which could both be used by \c app.qml without import statements. */ + /*! -\page qml-extending-tutorial6.html -\title Chapter 6: In Summary +\page qml-extending-tutorial7.html +\title Chapter 7: In Summary In this tutorial, we've shown the basic steps for creating a QML extension: @@ -362,47 +474,33 @@ In this tutorial, we've shown the basic steps for creating a QML extension: \o Add callable methods using Q_INVOKABLE or Qt slots, and connect to Qt signals with an \c onSignal syntax \o Add property bindings by defining \l{Qt's Property System}{NOTIFY} signals \o Define custom property types if the built-in types are not sufficient +\o Define list property types using QDeclarativeListProperty \o Create a plugin library by defining a Qt plugin and writing a \c qmldir file \endlist The \l {Extending QML in C++} reference documentation shows other useful features that can be added to -QML extensions. For example, we could use \l{Object and List Property Types}{list properties} to allow multiple instruments for a \c Musician: +QML extensions. For example, we could use \l{Default Property}{default properties} to allow +slices to be added without using the \c slices property: \code - Musician { - instruments: [ - Instrument { type: "Guitar" } - Instrument { type: "Drums" } - Instrument { type: "Keyboard" } - ] + PieChart { + PieSlice { ... } + PieSlice { ... } + PieSlice { ... } } \endcode -Or use \l{Default Property}{default properties} and avoid an -\c instruments property altogether: +Or randomly add and remove slices from time to time using \l{Property Value Sources}{property value sources}: \code - Musician { - Instrument { type: "Guitar" } - Instrument { type: "Drums" } - Instrument { type: "Keyboard" } - } -\endcode - -Or even change the \c instrument of a \c Musician from time to time using \l{Property Value Sources}{property value sources}: - -\code - Musician { - InstrumentRandomizer on instrument {} + PieChart { + PieSliceRandomizer on slices {} } \endcode See the \l{Extending QML in C++}{reference documentation} for more information. -Additionally, \l {Integrating QML with existing Qt UI code} shows how to create -and integrate with QML extensions that have drawing and graphical capabilities (through QGraphicsWidget). - */ diff --git a/doc/src/declarative/focus.qdoc b/doc/src/declarative/focus.qdoc index 0dd5eb3..56ea165 100644 --- a/doc/src/declarative/focus.qdoc +++ b/doc/src/declarative/focus.qdoc @@ -73,12 +73,12 @@ See also the \l {Keys}{Keys attached property} and \l {KeyNavigation}{KeyNavigat \section1 Querying the Active Focus Item Whether or not an \l Item has \e {active focus} can be queried through the -property \c {Item::focus}. For example, here we have a \l Text +property \c {Item::activeFocus}. For example, here we have a \l Text element whose text is determined by whether or not it has \e {active focus}. \code Text { - text: focus ? "I have active focus!" : "I do not have active focus" + text: activeFocus ? "I have active focus!" : "I do not have active focus" } \endcode @@ -174,7 +174,7 @@ Rectangle { The right hand side of the example shows the expanded code - the equivalent QML without the use of the component \c {MyWidget}. From this, the problem is evident - there are no less than three elements that have the \c {Item::focus} -property set to true. Ultimately only one element can have focus, and the +property set to true. Ultimately only one element can have keyboard focus, and the system has to decide which on. In this case the first appearance of the \c {Item::focus} property being set to true on line 4 is selected, and the value of \c {Item::focus} in the other two instances is reverted back to false. This @@ -233,7 +233,7 @@ and the others are unset, just like when there are no \e {focus scopes}. \o When a \e {focus scope} receives \e {active focus}, the contained element with \c {Item::focus} set (if any) also gets \e {active focus}. If this element is also a \l FocusScope, the proxying behaviour continues. Both the -\e {focus scope} and the sub-focused item will have \c {Item::focus} set. +\e {focus scope} and the sub-focused item will have \c {Item::activeFocus} set. \endlist So far the example has the second component statically selected. It is trivial @@ -266,7 +266,7 @@ When a QML item explicitly relinquishes focus (by setting its does not automatically select another element to receive focus. That is, it is possible for there to be no currently \e {active focus}. -See the {declarative/keyinteraction/focus}{Keyboard Focus example} for a +See the \l{declarative/keyinteraction/focus}{Keyboard Focus example} for a demonstration of moving keyboard focus between multiple areas using FocusScope elements. diff --git a/doc/src/declarative/javascriptblocks.qdoc b/doc/src/declarative/javascriptblocks.qdoc index c41e38e..18da3d2 100644 --- a/doc/src/declarative/javascriptblocks.qdoc +++ b/doc/src/declarative/javascriptblocks.qdoc @@ -236,6 +236,31 @@ This restriction exists as the QML environment is not yet fully established. To run code after the environment setup has completed, refer to \l {Running JavaScript at Startup}. +\o The value of \c this is currently undefined in QML + +The value of \c this is undefined in QML. To refer to any element, provide +an \c id. For example: + +\qml +Item { + width: 200; height: 100 + function mouseAreaClicked(area) { + console.log("Clicked in area at: " + area.x + ", " + area.y); + } + // This will not work because this is undefined + MouseArea { + height: 50; width: 200 + onClicked: mouseAreaClicked(this) + } + // This will pass area2 to the function + MouseArea { + id: area2 + y: 50; height: 50; width: 200 + onClicked: mouseAreaClicked(area2) + } +} +\endqml + \endlist */ diff --git a/doc/src/declarative/modules.qdoc b/doc/src/declarative/modules.qdoc index 938222a..9e51a40 100644 --- a/doc/src/declarative/modules.qdoc +++ b/doc/src/declarative/modules.qdoc @@ -30,152 +30,277 @@ \title Modules \section1 QML Modules -A \bold {QML module} is a collection of QML types. They allow you to organize your QML content -into independent units. Modules have an optional versioning mechanism that allows for independent + +A module is a set of QML content files that can be imported as a unit into a QML +application. Modules can be used to organize QML content into independent units, +and they can use a versioning mechanism that allows for independent upgradability of the modules. -There are two types of modules: -location modules (defined by a URL), -and -installed modules (defined by a URI). +While QML component files within the same directory are automatically accessible +within the global namespace, components defined elsewhere must be imported +explicitly using the \c import statement to import them as modules. For +example, an \c import statement is required to use: + +\list +\o A component defined in another QML file that is not in the same directory +\o A component defined in a QML file located on a remote server +\o A \l{QDeclarativeExtensionPlugin}{QML C++ plugin} library (unless the plugin is installed in the same directory) +\o A JavaScript file (note this must be imported using \l {#namespaces}{named imports}) +\endlist + +An \c import statement includes the module name, and possibly a version number. +This can be seen in the snippet commonly found at the top of QML files: + +\qml + import Qt 4.7 +\endqml + +This imports version 4.7 of the "Qt" module into the global namespace. (The QML +library itself must be imported to use any of the \l {QML Elements}, as they +are not included in the global namespace by default.) + +The \c Qt module is an \e installed module; it is found in the +\l{The QML import path}{import path}. There are two types of QML modules: +location modules (defined by a URL) and installed modules (defined by a URI). + + +\section1 Location Modules + +Location modules can reside on the local filesystem or a network resource, +and are referred to by a quoted location URL that specifies the filesystem +or network URL. They allow any directory with QML content to be imported +as a module, whether the directory is on the local filesystem or a remote +server. + +For example, a QML project may have a separate directory for a set of +custom UI components. These components can be accessed by importing the +directory using a relative or absolute path, like this: + +\table +\row +\o Directory structure +\o Contents of application.qml + +\row +\o +\code +MyQMLProject + |- MyComponents + |- Slider.qml + |- CheckBox.qml + |- Main + |- application.qml +\endcode + +\o +\code +import "../MyComponents" + +Slider { ... } +CheckBox { ... } +\endcode + +\endtable -Location modules types are defined in QML files and \l{QDeclarativeExtensionPlugin}{QML C++ plugins} -in a directory refered to directly by -the location URL, either on the local filesystem, or as a network resource. The URL that locates them -can be relative, in which case they actual URL is resolved by the QML file containing the import. -When importing a location module, a quoted URL is used: +Similarly, if the directory resided on a network source, it could +be imported like this: \code -import "https://qml.nokia.com/qml/example" 1.0 -import "https://qml.nokia.com/qml/example" as NokiaExample -import "mymodule" 1.0 -import "mymodule" + import "https://qml.nokia.com/qml/qmlcomponents" + import "https://qml.nokia.com/qml/qmlcomponents" 1.0 \endcode -Installed modules can \e only be on the local file system or in application C++ code. Again they -are defined in QML files and \l{QDeclarativeExtensionPlugin}{QML C++ plugins} in a directory, -but the directory is indirectly referred to by the URI. The mapping to actual content is either -by application C++ code registering a C++ type to a module URI (see \l{Extending QML in C++}), -or in the referenced subdirectory of a path on the import path (see below). -When importing a location module, an un-quoted URI is used: +Remote location modules must have a \l{Writing a qmldir file}{qmldir file} in the +same directory to specify which QML files should be made available. See the +\l {#qmldirexample}{example} below. The qmldir file is optional for modules on +the local filesystem. + + + +\section1 Installed modules + + +Installed modules are modules that are installed on the +local filesystem within the QML import path, or modules defined in C++ +application code. When importing an installed module, an un-quoted URI is +used, with a mandatory version number: \code -import com.nokia.qml.mymodule 1.0 -import com.nokia.qml.mymodule as MyModule + import Qt 4.7 + import com.nokia.qml.mymodule 1.0 \endcode +Installed modules that are installed into the import path or created +as a \l{QDeclarativeExtensionPlugin}{QML C++ plugin} must define a +\l{Writing a qmldir file}{qmldir file}. + + +\section2 The QML import path -For either type of module, a \c qmldir file in the module directory defines the content of the module. This file is -optional for location modules, but only for local filesystem content or a single remote content with a namespace. -The second exception is explained in more detail in the section below on Namespaces. +The QML engine will search the import path for a requested installed module. +The default import path includes: -\section2 The Import Path +\list +\o The directory of the current file +\o The location specified by QLibraryInfo::ImportsPath +\o Paths specified by the \c QML_IMPORT_PATH environment variable +\endlist -Installed modules are searched for on the import path. -The \c -I option to the \l {QML Viewer} adds paths to the import path. +The import path can be queried using QDeclarativeEngine::importPathList() and modified using QDeclarativeEngine::addImportPath(). -From C++, the path is available via \l QDeclarativeEngine::importPathList() and can be prepended to -using \l QDeclarativeEngine::addImportPath(). +When running the \l {QML Viewer}, use the \c -I option to add paths to the import path. -\section2 The \c qmldir File -Installed QML modules and remote content without a namespace require a file \c qmldir which -specifies the mapping from all type names to versioned QML files. It is a list of lines of the form: +\section2 Creating installed modules in C++ + +C++ applications can dynamically define installed modules using +qmlRegisterType(). + +For \l{QDeclarativeExtensionPlugin}{QML C++ plugins}, the +module URI is automatically passed to QDeclarativeExtensionPlugin::registerTypes(). +The QDeclarativeExtensionPlugin documentation shows how to use this URI +to call qmlRegisterType() to enable the plugin library to be built as +an installed module. Once the plugin is built and installed, the module is importable +in QML, like this: + +\code +import com.nokia.TimeExample 1.0 +\endcode + +A \l{QDeclarativeExtensionPlugin}{QML C++ plugin} also requires a +\l{Writing a qmldir file}{qmldir file} to make it available to the +QML engine. + + + +\target namespaces +\section1 Namespaces: Using Named Imports + +By default, when a module is imported, its contents are imported into the global namespace. You may choose to import the module into another namespace, either to allow identically-named types to be referenced, or purely for readability. + +To import a module into a specific namespace, use the \e as keyword: + +\qml + import Qt 4.7 as QtLibrary + import "../MyComponents" as MyComponents + import com.nokia.qml.mymodule 1.0 as MyModule +\endqml + +Types from these modules can then only be used when qualified by the namespace: + +\qml + QtLibrary.Rectangle { ... } + + MyComponents.Slider { ... } + + MyModule.SomeComponent { ... } +\endqml + +Multiple modules can be imported into the same namespace in the same way that multiple modules can be imported into the global namespace: + +\qml + import Qt 4.7 as Nokia + import Ovi 1.0 as Nokia +\endqml + +\section2 JavaScript files + +JavaScript files must always be imported with a named import: + +\qml + import "somescript.js" as MyScript + + Item { + //... + Component.onCompleted: MyScript.doSomething() + } +\endqml + + + +\section1 Writing a qmldir file + +A \c qmldir file is a metadata file for a module that maps all type names in +the module to versioned QML files. It is required for installed modules, and +location modules that are loaded from a network source. + +It is defined by a plain text file named "qmldir" that contains one or more lines of the form: \code # <Comment> <TypeName> [<InitialVersion>] <File> -internal <Name> <File> +internal <TypeName> <File> plugin <Name> [<Path>] \endcode -# <Comment> lines are ignored, and can be used for comments. +\bold {# <Commment>} lines are used for comments. They are ignored by the QML engine. -<TypeName> <InitialVersion> <File> lines are used to add QML files as types. -<TypeName> is the type being made available; the optional <InitialVersion> is a version -number like \c 4.0; <File> is the (relative) -file name of the QML file defining the type. +\bold {<TypeName> [<InitialVersion>] <File>} lines are used to add QML files as types. +<TypeName> is the type being made available, the optional <InitialVersion> is a version +number, and <File> is the (relative) file name of the QML file defining the type. Installed files do not need to import the module of which they are a part, as they can refer to the other QML files in the module as relative (local) files, but if the module is imported from a remote location, those files must nevertheless be listed in the \c qmldir file. Types which you do not wish to export to users of your module -may be marked with the \c internal keyword: \c internal <TypeName> <File>. +may be marked with the \c internal keyword: \bold {internal <TypeName> <File>}. The same type can be provided by different files in different versions, in which case later versions (eg. 1.2) must precede earlier versions (eg. 1.0), since the \e first name-version match is used and a request for a version of a type can be fulfilled by one defined in an earlier version of the module. If a user attempts to import a version earlier than the earliest provided or later than the latest provided, -an error results, but if the user imports a version within the range of versions provided, -even if no type is specific to that version, no error results. +the import produces a runtime error, but if the user imports a version within the range of versions provided, +even if no type is specific to that version, no error will occur. A single module, in all versions, may only be provided in a single directory (and a single \c qmldir file). If multiple are provided, only the first in the search path will be used (regardless of whether other versions are provided by directories later in the search path). -Installed and remote files without a namespace \e must be referred to by version information described above, -local files \e may have it. - The versioning system ensures that a given QML file will work regardless of the version of installed software, since a versioned import \e only imports types for that version, leaving other identifiers available, even if the actual installed version might otherwise provide those identifiers. -\c plugin <Name> [<Path>] lines are used to add \l{QDeclarativeExtensionPlugin}{QML C++ plugins} -to the module. - -<Name> is the name of the library. It is usually not the same as the file name -of the plugin binary, which is platform dependent; e.g. the library MyAppTypes would produce -a libMyAppTypes.so on Linux and MyAppTypes.dll on Windows. -By default the engine searches for the plugin library in the directory containing the \c qmldir -file. The \c -P option to the \l {QML Viewer} adds paths to the -plugin search path. -From C++, the path is available via \l QDeclarativeEngine::pluginPathList() and can be prepended to -using \l QDeclarativeEngine::addPluginPath(). +\bold {plugin <Name> [<Path>]} lines are used to add \l{QDeclarativeExtensionPlugin}{QML C++ plugins} to the module. <Name> is the name of the library. It is usually not the same as the file name +of the plugin binary, which is platform dependent; e.g. the library \c MyAppTypes would produce +\c libMyAppTypes.so on Linux and \c MyAppTypes.dll on Windows. <Path> is an optional argument specifying either an absolute path to the directory containing the plugin file, or a relative path from the directory containing the \c qmldir file to the directory -containing the plugin file. - +containing the plugin file. By default the engine searches for the plugin library in the directory that contains the \c qmldir +file. The plugin search path can be queried with QDeclarativeEngine::pluginPathList() and modified using QDeclarativeEngine::addPluginPath(). When running the \l {QML Viewer}, use the \c -P option to add paths to the plugin search path. -\section2 Namespaces - Named Imports -When importing content it by default imports types into the global namespace. -You may choose to import the module into another namespace, either to allow identically-named -types to be referenced, or purely for readability. +\target qmldirexample +\section2 Example -To import a module into a namespace: +If the components in the \c MyComponents directory from the +\l{Location Modules}{earlier example} were to be made available as a network resource, +the directory would need to contain a \c qmldir file similar to this: \code -import Qt 4.7 as TheQtLibrary +ComponentA 1.0 ComponentA.qml +ComponentB 1.0 ComponentB.qml \endcode -Types from the Qt 4.7 module may then be used, but only by qualifying them with the namespace: +The \c MyComponents directory could then be imported as a module using: \code -TheQtLibrary.Rectangle { ... } -\endcode - -Multiple modules can be imported into the same namespace in the same way that multiple -modules can be imported into the global namespace: +import "http://the-server-name.com/MyComponents" -\code -import Qt 4.7 as Nokia -import Ovi 1.0 as Nokia +Slider { ... } +CheckBox { ... } \endcode -While import statements are needed to make any types available in QML, the directory of the -current file is implicitly loaded. This is the exact same as if you had added 'import "."' to -the start of every QML file. The effect of this is that you can automatically use types defined in C++ plugins -or QML files if they reside in the same directory. This is the last location searched for types - so if you -happen to have a "Text.qml" file, or "text.qml" on case-insensitive file systems, it will not override -the one from Qt if you import Qt. - -*/ +with an optional "1.0" version specification. Notice the import fails if +a later version is used, as the \c qmldir file specifies that these elements +are only available in the 1.0 version. -/* -Original requirement is QT-558. +For examples of \c qmldir files for plugins, see the +\l {declarative/cppextensions/plugins}{Plugins} example and +\l {Tutorial: Writing QML extensions with C++}. */ +/ diff --git a/doc/src/declarative/pics/anatomy-component.png b/doc/src/declarative/pics/anatomy-component.png Binary files differindex 70ed983..6125b00 100644 --- a/doc/src/declarative/pics/anatomy-component.png +++ b/doc/src/declarative/pics/anatomy-component.png diff --git a/doc/src/declarative/pics/extending-tutorial-chapter1.png b/doc/src/declarative/pics/extending-tutorial-chapter1.png Binary files differnew file mode 100644 index 0000000..9f5836b --- /dev/null +++ b/doc/src/declarative/pics/extending-tutorial-chapter1.png diff --git a/doc/src/declarative/pics/extending-tutorial-chapter2.png b/doc/src/declarative/pics/extending-tutorial-chapter2.png Binary files differnew file mode 100644 index 0000000..5c8f222 --- /dev/null +++ b/doc/src/declarative/pics/extending-tutorial-chapter2.png diff --git a/doc/src/declarative/pics/extending-tutorial-chapter3.png b/doc/src/declarative/pics/extending-tutorial-chapter3.png Binary files differnew file mode 100644 index 0000000..825553f --- /dev/null +++ b/doc/src/declarative/pics/extending-tutorial-chapter3.png diff --git a/doc/src/declarative/pics/extending-tutorial-chapter5.png b/doc/src/declarative/pics/extending-tutorial-chapter5.png Binary files differnew file mode 100644 index 0000000..0c2e69e --- /dev/null +++ b/doc/src/declarative/pics/extending-tutorial-chapter5.png diff --git a/doc/src/declarative/qdeclarativedocument.qdoc b/doc/src/declarative/qdeclarativedocument.qdoc index a2ed205..068297a 100644 --- a/doc/src/declarative/qdeclarativedocument.qdoc +++ b/doc/src/declarative/qdeclarativedocument.qdoc @@ -73,51 +73,61 @@ document - such as \c Rectangle and \c ListView - including those made within an import statements. QML does not import any modules by default, so at least one \c import statement must be present or no elements will be available! +Each \c id value in a QML document must be unique within that document. They +do not need to be unique across different documents as id values are +resolved according to the document scope. + + +\section1 Documents as Component Definitions + A QML document defines a single, top-level \l {QDeclarativeComponent}{QML component}. A QML component is a template that is interpreted by the QML runtime to create an object with some predefined behaviour. As it is a template, a single QML component can be "run" multiple times to produce several objects, each of which are said to be \e instances of the component. Once created, instances are not dependent on the component that created them, so they can -operate on independent data. Here is an example of a simple "Button" component that is -instantiated four times, each with a different value for its \c text property. +operate on independent data. Here is an example of a simple "Button" component (defined +in a \c Button.qml file) that is instantiated four times by \c application.qml. +Each instance is created with a different value for its \c text property: -\raw HTML -<table><tr><td> -\endraw -\code +\table +\row +\o Button.qml +\o application.qml + +\row +\o \snippet doc/src/snippets/declarative/qmldocuments.qml 0 +\o +\qml import Qt 4.7 -BorderImage { - property alias text: textElement.text - width: 100; height: 30; source: "images/toolbutton.sci" - - Text { - id: textElement - anchors.centerIn: parent - font.pointSize: 20 - style: Text.Raised - color: "white" - } +Column { + spacing: 10 + + Button { text: "Apple" } + Button { text: "Orange" } + Button { text: "Pear" } + Button { text: "Grape" } } -\endcode -\raw HTML -</td> <td> -\endraw +\endqml + \image anatomy-component.png -\raw HTML -</td> </tr> </table> -\endraw + +\endtable Any snippet of QML code can become a component, just by placing it in the file "<Name>.qml" -where <Name> is the new element name, and begins with an uppercase letter. Note that +where <Name> is the new element name, and begins with an \bold uppercase letter. Note that the case of all characters in the <Name> are significant on some filesystems, notably UNIX filesystems. It is recommended that the case of the filename matches the case of the component name in QML exactly, regardless of the platform the QML will be deployed to. -These QML files automatically become available as new QML element types +These QML component files automatically become available as new QML element types to other QML components and applications in the same directory. + + +\section1 Inline Components + In addition to the top-level component that all QML documents define, and any reusable components placed in separate files, documents may also include \e inline components. Inline components are declared using the diff --git a/doc/src/declarative/qdeclarativei18n.qdoc b/doc/src/declarative/qdeclarativei18n.qdoc index b6e6c6e..70a3587 100644 --- a/doc/src/declarative/qdeclarativei18n.qdoc +++ b/doc/src/declarative/qdeclarativei18n.qdoc @@ -80,5 +80,5 @@ qmlviewer -translation hello.qm hello.qml \endcode -You can see a complete example and source code in the {declarative/i18n}{QML Internationalization example}. +You can see a complete example and source code in the \l{declarative/i18n}{QML Internationalization example}. */ diff --git a/doc/src/declarative/qdeclarativeintro.qdoc b/doc/src/declarative/qdeclarativeintro.qdoc index 9126a79..fa42f59 100644 --- a/doc/src/declarative/qdeclarativeintro.qdoc +++ b/doc/src/declarative/qdeclarativeintro.qdoc @@ -87,6 +87,10 @@ Rectangle { width: 100; height: 100 } When multiple property/value pairs are specified on a single line, they must be separated by a semicolon. +The \c import statement imports the \c Qt \l{QML Modules}{module}, which contains all of the +standard \l {QML Elements}. Without this import statement, the \l Rectangle +and \l Image elements would not be available. + \section1 Expressions In addition to assigning values to properties, you can also assign @@ -129,7 +133,7 @@ Commenting in QML is similar to JavaScript. \o Multiline comments start with /* and finish with *\/ \endlist -\quotefile doc/src/snippets/declarative/comments.qml +\snippet doc/src/snippets/declarative/comments.qml 0 Comments are ignored by the engine. They are useful for explaining what you are doing; for referring back to at a later date, or for others reading @@ -181,7 +185,8 @@ Item { \section3 The \c id property -Each object can be given a special unique property called an \e id. Assigning an id enables the object +Each object can be given a special unique property called an \e id. No other object within the +same \l{QML Documents}{QML document} can have the same \c id value. Assigning an id enables the object to be referred to by other objects and scripts. The first Rectangle element below has an \e id, "myRect". The second Rectange element defines its @@ -314,7 +319,7 @@ Item { \section2 Signal Handlers -Signal handlers allow actions to be taken in reponse to an event. For instance, +Signal handlers allow actions to be taken in response to an event. For instance, the \l MouseArea element has signal handlers to handle mouse press, release and click: diff --git a/doc/src/declarative/qdeclarativemodels.qdoc b/doc/src/declarative/qdeclarativemodels.qdoc index b44e6f2..173002a 100644 --- a/doc/src/declarative/qdeclarativemodels.qdoc +++ b/doc/src/declarative/qdeclarativemodels.qdoc @@ -208,7 +208,10 @@ Models can be defined in C++ and then made available to QML. This is useful for exposing existing C++ data models or otherwise complex datasets to QML. A C++ model class can be defined as a QStringList, a QList<QObject*> or a -QAbstractItemModel. +QAbstractItemModel. The first two are useful for exposing simpler datasets, +while QAbstractItemModel provides a more flexible solution for more complex +models. + \section2 QStringList @@ -268,7 +271,10 @@ the model by calling QDeclarativeContext::setContextProperty() again. \section2 QAbstractItemModel -A model can be defined by subclassing QAbstractItemModel. +A model can be defined by subclassing QAbstractItemModel. This is the +best approach if you have a more complex model that cannot be supported +by the other approaches. A QAbstractItemModel can also automatically +notify a QML view when the model data has changed. The roles of a QAbstractItemModel subclass can be exposed to QML by calling QAbstractItemModel::setRoleNames(). The default role names set by Qt are: @@ -305,6 +311,12 @@ roles: \snippet examples/declarative/modelviews/abstractitemmodel/view.qml 0 +QML views are automatically updated when the model changes. Remember the model +must follow the standard rules for model changes and notify the view when +the model has changed by using QAbstractItemModel::dataChanged(), +QAbstractItemModel::beginInsertRows(), etc. See the \l {Model subclassing reference} for +more information. + The complete example is available in Qt's \l {declarative/modelviews/abstractitemmodel}{examples/declarative/modelviews/abstractitemmodel} directory. QAbstractItemModel presents a hierarchy of tables, but the views currently provided by QML @@ -429,4 +441,77 @@ Rectangle { } \endcode +\section1 Accessing Views and Models from Delegates + +You can access the view for which a delegate is used, and its +properties, by using ListView.view in a delegate on a ListView, or +GridView.view in a delegate on a GridView, etc. In particular, you can +access the model and its properties by using ListView.view.model. + +This is useful when you want to use the same delegate for a number of +views, for example, but you want decorations or other features to be +different for each view, and you would like these different settings to +be properties of each of the views. Similarly, it might be of interest +to access or show some properties of the model. + +In the following example, the delegate shows the property \e{language} +of the model, and the color of one of the fields depends on the +property \e{fruit_color} of the view. + +\code +Rectangle { + width: 200; height: 200 + + ListModel { + id: fruitModel + property string language: "en" + ListElement { + name: "Apple" + cost: 2.45 + } + ListElement { + name: "Orange" + cost: 3.25 + } + ListElement { + name: "Banana" + cost: 1.95 + } + } + + Component { + id: fruitDelegate + Row { + Text { text: " Fruit: " + name; color: ListView.view.fruit_color } + Text { text: " Cost: $" + cost } + Text { text: " Language: " + ListView.view.model.language } + } + } + + ListView { + property color fruit_color: "green" + model: fruitModel + delegate: fruitDelegate + anchors.fill: parent + } +} +\endcode + +Another important case is when some action (e.g. mouse click) in the +delegate should update data in the model. In this case you can define +a function in the model, e.g.: + +\code + setData(int row, const QString & field_name, QVariant new_value), +\endcode + +...and call it from the delegate using: + +\code + ListView.view.model.setData(index, field, value) +\endcode + +...assuming that \e{field} holds the name of the field which should be +updated, and that \e{value} holds the new value. + */ diff --git a/doc/src/declarative/qdeclarativestates.qdoc b/doc/src/declarative/qdeclarativestates.qdoc index 6461925..0b91756 100644 --- a/doc/src/declarative/qdeclarativestates.qdoc +++ b/doc/src/declarative/qdeclarativestates.qdoc @@ -32,57 +32,174 @@ \section1 Overview -QML states typically describe user interface configurations, including: +User interfaces are designed to present different interface configurations in +different scenarios, or to modify their appearances in response to user +interaction. Often, there are a set of changes that are made concurrently, such +that the interface could be seen to be internally changing from one \e state to +another. + +This applies generally to interface elements regardless of their complexity. +A photo viewer may initially present images in a grid, and when an image is +clicked, change to a "detailed" state where the individual image is expanded +and the interface is changed to present new options for image editing. On the +other end of the scale, when a simple button is pressed, it may change to a +"pressed" state in which its color and position is modified to give a pressed +appearance. + +In QML, any object can change between different \e states to apply sets of +changes that modify the properties of relevant items. Each \e state could +present a different configuration that could, for example: + \list -\o What UI elements are present -\o The properties of those elements (including how they behave) -\o What actions are available +\o Show some UI elements and hide others +\o Present different available actions to the user +\o Start, stop or pause animations +\o Execute some script required in the new state +\o Change a property value for a particular item +\o Show a different view or "screen" \endlist -A state can also be thought of as a set of batched changes from a default configuration. +Changes between states can be animated using \l {Transitions}{transitions}, as +discussed further below. -Examples of states in modern UI: -\list -\o An Address Book application with a 'View Contact' state and an 'Edit Contact' State. In the first state the contact information presented is read-only (using labels), and in the second it is editable (using editors). -\o A button with a pressed and unpressed state. When pressed the text moves slightly down and to the right, and the button has a slightly darker appearance. -\endlist +All \l {Item}-based objects have a \e {default state}, and can specify additional +states by adding new \l State objects to the item's \l {Item::}{states} +property. Each state has a \e name that is unique for all states within that +item; the default state's name is an empty string. To change the current state +of an item, set the \l {Item::}{state} property to the name of the state. + +Non-Item objects can use states through the StateGroup element. -\section1 States in QML -In QML: +\section1 Creating states + +To create a state, add a \l State object to the item's \l {Item::}{states} property, +which holds a list of states for that item. + +Following is an example. Here, the \l Rectangle is initially placed in the +default (0, 0) position. It has defined an additional state named "moved", in +which a PropertyChanges object repositions the rectangle to (50, 50). Clicking +within the MouseArea changes the state to the "moved" state, thus moving the \l +Rectangle. + +\snippet doc/src/snippets/declarative/states.qml 0 + +A \l State item defines all the changes to be made in the new state. You +could specify additional properties to be changed, or create additional +PropertyChanges for other objects. (Note that a \l State can modify the +properties of other objects, not just the object that owns the state.) + +For example: + +\qml +State { + name: "moved" + PropertyChanges { target: myRect; x: 50; y: 50; color: "blue" } + PropertyChanges { target: someOtherItem; width: 1000 } +} +\endqml + +A \l State is not limited to performing modifications on property values. It +can also: + \list -\o Any object can use states. -\o There is a default state. The default state can be explicitly set. -\o A state can affect the properties of other objects, not just the object owning the state (and not just that object's children). +\o Run some script using StateChangeScript +\o Override an existing signal handler for an object using PropertyChanges +\o Re-parent an \l Item using ParentChanges +\o Modify anchor values using AnchorChanges \endlist -To define a state for an item, add a \l State element to the \l{Item::states}{states} property. To -change the current state of an \l Item, set the \l{Item::state}{state} property to the name -of the required state. +The \l {declarative/animation/states}{States and Transitions example} +demonstrates how to declare a basic set of states and apply animated +transitions between them. -Here is an example of using states. In the default state \c myRect is positioned at 0,0. In the 'moved' state it is positioned at 50,50. Clicking within the mouse area changes the state from the default state to the 'moved' state, thus moving the rectangle. -\snippet doc/src/snippets/declarative/states.qml 0 -\snippet doc/src/snippets/declarative/states.qml 1 +\section1 The default state -State changes can be animated using \l{state-transitions}{Transitions}. +Of course, the \l Rectangle in the example above could have simply been moved +by setting its position to (50, 50) in the mouse area's \c onClicked handler. +However, aside from enabling batched property changes, the use of states allows +an item to revert to its \e {default state}, which contains all of the items' +initial property values before they were modified in a state change. -For example, adding this code to the above \c Item element animates the transition to the "moved" state: +The default state is specified by an empty string. If the MouseArea in the +above example was changed to this: -\snippet doc/src/snippets/declarative/states.qml transitions +\qml +MouseArea { + anchors.fill: parent + onClicked: myRect.state == 'moved' ? myRect.state = "" : myRect.state = 'moved'; +} +\endqml -See \l{state-transitions}{Transitions} for more information. +This would toggle the \l Rectangle's state between the \e moved and \e default +states when clicked. The properties can be reverted to their initial +values without requiring the definition of another \l State that defines these +value changes. -Other things you can do in a state change: -\list -\o Override signal handlers with PropertyChanges -\o Change an item's visual parent with ParentChange -\o Change an item's anchors with AnchorChanges -\o Run some script with StateChangeScript -\endlist +\section1 The "when" property + +The \l {State::}{when} property is useful for specifying when a state should be +applied. This can be set to an expression that evaluates to \c true when an +item should change to a particular state. + +If the above example was changed to this: + +\qml +Rectangle { + ... + + MouseArea { + id: mouseArea + anchors.fill: parent + } + + states: State { + name: "moved"; when: mouseArea.pressed + ... + } +\endqml + +The \l Rectangle would automatically change to the \e moved state when the +mouse is pressed, and revert to the default state when it is released. This is +simpler (and a better, more declarative method) than creating \c onPressed +and \c onReleased handlers in the MouseArea to set the current state. + + +\section1 Animating state changes + + +State changes can be easily animated through \l {Transitions}{transitions}. A +\l Transition defines the animations that should be applied when an item +changes from one state to another. + +If the above example was modified to include the following \l Transition, the +movement of the \l Rectangle would be animated: + +\qml +Rectangle { + ... + + MouseArea { ... } + + states: [ + ... + ] + + transitions: [ + Transition { + NumberAnimation { properties: "x,y"; duration: 500 } + } + ] + } +\endqml + +This \l Transition defines that if any \c x or \c y properties have changed +during a state change within this item, their values should be animated over 500 +millliseconds. -The {declarative/animation/states}{States and Transitions example} demonstrates how to declare a basic set of states and then apply animated transitions between them. +See the \l Transitions documentation for more information. */ diff --git a/doc/src/declarative/qmlviewer.qdoc b/doc/src/declarative/qmlviewer.qdoc index 5efc0ce..41c4c80 100644 --- a/doc/src/declarative/qmlviewer.qdoc +++ b/doc/src/declarative/qmlviewer.qdoc @@ -197,10 +197,10 @@ Rectangle { \o \c runtime.orientation \o This property indicates the current orientation of the QML Viewer. On the -N900 platform, this property automatically updates to reflect the device's -actual orientation; on other platforms, this indicates the orientation currently -selected in the QML Viewer's \e {Settings -> Properties} menu. The -\c orientation value can be one of the following: +N900 platform and most S60 5.0-based or newer Symbian devices, this property +automatically updates to reflect the device's actual orientation; on other platforms, +this indicates the orientation currently selected in the QML Viewer's +\e {Settings -> Properties} menu. The \c orientation value can be one of the following: \list \o \c Orientation.Portrait diff --git a/doc/src/declarative/qtdeclarative.qdoc b/doc/src/declarative/qtdeclarative.qdoc index fb50286..413eb59 100644 --- a/doc/src/declarative/qtdeclarative.qdoc +++ b/doc/src/declarative/qtdeclarative.qdoc @@ -70,13 +70,23 @@ Returns the QML type id. - Example: Register the C++ class \c MinehuntGame as the QML type - named \c Game for version 0.1 in the import library \c MinehuntCore: + For example, this registers a C++ class \c MySliderItem as a QML type + named \c Slider for version 1.0 of a \l{QML Modules}{module} called + "com.mycompany.qmlcomponents": \code - qmlRegisterType<MinehuntGame>("MinehuntCore", 0, 1, "Game"); + qmlRegisterType<MySliderItem>("com.mycompany.qmlcomponents", 1, 0, "Slider"); \endcode + Once this is registered, the type can be used in QML by importing the + specified module name and version number: + + \qml + imoprt com.mycompany.qmlcomponents 1.0 + + Slider { ... } + \endqml + Note that it's perfectly reasonable for a library to register types to older versions than the actual version of the library. Indeed, it is normal for the new library to allow QML written to previous versions to continue to work, even if more advanced versions of diff --git a/doc/src/declarative/tutorial.qdoc b/doc/src/declarative/tutorial.qdoc index 7a97eb1..f913d44 100644 --- a/doc/src/declarative/tutorial.qdoc +++ b/doc/src/declarative/tutorial.qdoc @@ -222,5 +222,5 @@ This is equivalent to writing the two transitions separately. The \l ParallelAnimation element makes sure that the two types of animations (number and color) start at the same time. We could also run them one after the other by using \l SequentialAnimation instead. -For more details on states and transitions, see \l {QML States} and the {declarative/animation/states}{states and transitions example}. +For more details on states and transitions, see \l {QML States} and the \l{declarative/animation/states}{states and transitions example}. */ |
