Merge branch '4.7' of scm.dev.nokia.troll.no:qt/oslo-staging-2 into 4.7

19 files changed, 305 insertions, 143 deletions

diff --git a/doc/src/declarative/declarativeui.qdoc b/doc/src/declarative/declarativeui.qdoc
index cc61c01..f310484 100644
--- a/doc/src/declarative/declarativeui.qdoc
+++ b/doc/src/declarative/declarativeui.qdoc
@@ -94,6 +94,7 @@ completely new applications.  QML is fully \l {Extending QML in C++}{extensible
 \o \l {qdeclarativefocus.html}{Keyboard Focus}
 \o \l {Extending types from QML}
 \o \l {Dynamic Object Creation}
+\o \l {qmlruntime.html}{The Qt Declarative Runtime}
 \endlist
 
 \section1 Reference:
diff --git a/doc/src/declarative/elements.qdoc b/doc/src/declarative/elements.qdoc
index e35d67c..fcfc7d6 100644
--- a/doc/src/declarative/elements.qdoc
+++ b/doc/src/declarative/elements.qdoc
@@ -77,11 +77,11 @@ The following table lists the QML elements provided by the Qt Declarative module
 \o \l PauseAnimation
 \o \l ParentAnimation
 \o \l AnchorAnimation
+\o \l SmoothedAnimation
 \o \l PropertyAction
 \o \l ScriptAction
 \o \l Transition
 \o \l SpringFollow
-\o \l EaseFollow
 \o \l Behavior
 \endlist
 
@@ -97,7 +97,6 @@ The following table lists the QML elements provided by the Qt Declarative module
 
 \o
 \list
-\o \l Script
 \o \l Connections
 \o \l Component
 \o \l Timer
@@ -180,6 +179,7 @@ The following table lists the QML elements provided by the Qt Declarative module
 \o \l Column
 \o \l Row
 \o \l Grid
+\o \l Flow
 \endlist
 
 \o
diff --git a/doc/src/declarative/examples.qdoc b/doc/src/declarative/examples.qdoc
index b7da508..3d8325e 100644
--- a/doc/src/declarative/examples.qdoc
+++ b/doc/src/declarative/examples.qdoc
@@ -51,21 +51,17 @@ sub-directory that show how to use various aspects of QML. In addition, the
 applications. These demos are intended to show integrated functionality
 rather than being instructive on specifice elements.
 
-To run the examples and demos, use the included \l {qmlviewer}{qmlviewer}
+To run the examples and demos, use the included \l {Qt Declarative UI Runtime}{qml}
 application. It has some useful options, revealed by:
 
 \code
-    bin/qmlviewer -help
+    bin/qml -help
 \endcode
 
 For example, from your build directory, run:
 
 \code
-    bin/qmlviewer $QTDIR/demos/declarative/flickr/flickr-desktop.qml
-\endcode
-or
-\code
-    bin/qmlviewer $QTDIR/demos/declarative/samegame/samegame.qml
+    bin/qml $QTDIR/demos/declarative/samegame/samegame.qml
 \endcode
 
 \section1 Examples
diff --git a/doc/src/declarative/extending.qdoc b/doc/src/declarative/extending.qdoc
index 8c096da..b6aa9da 100644
--- a/doc/src/declarative/extending.qdoc
+++ b/doc/src/declarative/extending.qdoc
@@ -654,9 +654,8 @@ declaring a new property, and the corresponding C++ type.
 \row \o string \o QString
 \row \o url \o QUrl
 \row \o color \o QColor
-\row \o date \o QDate
+\row \o date \o QDateTime
 \row \o var \o QVariant
-\row \o variant \o QVariant
 \endtable
 
 QML supports two methods for adding a new property to a type: a new property
@@ -693,6 +692,19 @@ it in two steps, like this:
     myProperty: 10
 \endcode
 
+If a default value is not supplied or set later in the file, each type has a
+default value for when none is explictly set. Below are the default values 
+of some of the types. For the remaining types the default values are undefined.
+
+\table
+\header \o QML Type \o Default Value
+\row \o bool \o false
+\row \o int \o 0
+\row \o double, real \o 0.0
+\row \o string, url \o "" (an empty string)
+\row \o color \o #000000 (black)
+\endtable
+
 If specified, the optional "default" attribute marks the new property as the
 types default property, overriding any existing default property.  Using the
 default attribute twice in the same type block is an error.
diff --git a/doc/src/declarative/focus.qdoc b/doc/src/declarative/focus.qdoc
index d7e890c..e5c1d32 100644
--- a/doc/src/declarative/focus.qdoc
+++ b/doc/src/declarative/focus.qdoc
@@ -96,7 +96,7 @@ Text {
 An \l Item requests focus by setting the \c {Item::focus} property to true.
 
 For very simple cases simply setting the \c {Item::focus} property is sometimes
-sufficient.  If we run the following example in the \c qmlviewer, we see that
+sufficient.  If we run the following example with the \l {Qt Declarative UI Runtime}{qml} tool, we see that
 the \c {keyHandler} element has \e {active focus} and pressing the 'A', 'B'
 or 'C' keys modifies the text appropriately.
 
diff --git a/doc/src/declarative/globalobject.qdoc b/doc/src/declarative/globalobject.qdoc
index 9f6be12..231e75a 100644
--- a/doc/src/declarative/globalobject.qdoc
+++ b/doc/src/declarative/globalobject.qdoc
@@ -189,6 +189,20 @@ This function attempts to open the specified \c target url in an external applic
 \section3 Qt.md5(data)
 This function returns a hex string of the md5 hash of \c data.
 
+\section3 Qt.btoa(data)
+This function returns a base64 encoding of \c data.
+
+\section3 Qt.atob(data)
+This function returns a base64 decoding of \c data.
+
+\section3 Qt.quit()
+This function causes the QML engine to emit the quit signal, which in
+\l {Qt Declarative UI Runtime}{qml} causes the runtime to quit.
+
+\section3 Qt.resolvedUrl(url)
+This function returns \c url resolved relative to the URL of the
+caller.
+
 \section1 Dynamic Object Creation
 The following functions on the global object allow you to dynamically create QML
 items from files or strings. See \l{Dynamic Object Management} for an overview
@@ -273,20 +287,33 @@ of their use.
 QML script supports the XMLHttpRequest object, which can be used to asynchronously obtain data from over a network.
 \section2 XMLHttpRequest()
 In QML you can construct an XMLHttpRequest object just like in a web browser! TODO: Real documentation for this object.
+
+
 \section1 Offline Storage API
 
-The \c openDatabase() and related functions
+\section2 Database API
+
+The \c openDatabaseSync() and related functions
 provide the ability to access local offline storage in an SQL database.
 
-These databases are user-specific and QML-specific. They are stored in the \c Databases subdirectory
+These databases are user-specific and QML-specific, but accessible to all QML applications.
+They are stored in the \c Databases subdirectory
 of QDeclarativeEngine::offlineStoragePath(), currently as SQLite databases.
 
+The API can be used from JavaScript functions in your QML:
+
+\quotefile declarative/sql/hello.qml
+
 The API conforms to the Synchronous API of the HTML5 Web Database API,
 \link http://www.w3.org/TR/2009/WD-webdatabase-20091029/ W3C Working Draft 29 October 2009\endlink.
 
-The API can be used from JavaScript functions in your QML:
+\section3 db = openDatabaseSync(identifier, version, description, estimated_size, callback(db))
 
-\quotefile declarative/sql/hello.qml
+Returns the database identified by \e identifier. If the database does not already exist, it
+is created with the properties \e description and \e estimated_size and the function \e callback
+is called with the database as a parameter.
+
+May throw exception with code property SQLException.DATABASE_ERR, or SQLException.VERSION_ERR.
 
 When a database is first created, an INI file is also created specifying its characteristics:
 
@@ -301,4 +328,48 @@ When a database is first created, an INI file is also created specifying its cha
 
 This data can be used by application tools.
 
+\section3 db.changeVersion(from, to, callback(tx))
+
+This method allows you to perform a \e{Scheme Upgrade}.
+
+If the current version of \e db is not \e from, then an exception is thrown.
+
+Otherwise, a database transaction is created and passed to \e callback. In this function,
+you can call \e executeSql on \e tx to upgrade the database.
+
+May throw exception with code property SQLException.DATABASE_ERR or SQLException.UNKNOWN_ERR.
+
+\section3 db.transaction(callback(tx))
+
+This method creates a read/write transaction and passed to \e callback. In this function,
+you can call \e executeSql on \e tx to read and modify the database.
+
+If the callback throws exceptions, the transaction is rolled back.
+
+\section3 db.readTransaction(callback(tx))
+
+This method creates a read-only transaction and passed to \e callback. In this function,
+you can call \e executeSql on \e tx to read the database (with SELECT statements).
+
+\section3 results = tx.executeSql(statement, values)
+
+This method executes a SQL \e statement, binding the list of \e values to SQL positional parameters ("?").
+
+It returns a results object, with the following properties:
+
+\table
+\header \o \bold {Type} \o \bold {Property} \o \bold {Value} \o \bold {Applicability}
+\row \o int \o rows.length \o The number of rows in the result \o SELECT
+\row \o var \o rows.item(i) \o Function that returns row \e i of the result \o SELECT
+\row \o int \o rowsAffected \o The number of rows affected by a modification \o UPDATE, DELETE
+\row \o string \o insertId \o The id of the row inserted \o INSERT
+\endtable
+
+May throw exception with code property SQLException.DATABASE_ERR, SQLException.SYNTAX_ERR, or SQLException.UNKNOWN_ERR.
+
+\section1 Logging
+
+\c console.log() and \c console.debug() can be used to print information
+to the console. See \l{Debugging QML} for more information.
+
 */
diff --git a/doc/src/declarative/javascriptblocks.qdoc b/doc/src/declarative/javascriptblocks.qdoc
index e57439f..c198295 100644
--- a/doc/src/declarative/javascriptblocks.qdoc
+++ b/doc/src/declarative/javascriptblocks.qdoc
@@ -244,7 +244,7 @@ var initialPosition = { rootObject.x, rootObject.y }
 
 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 Script at Startup}.
+\l {Running JavaScript at Startup}.
 
 \endlist
 
diff --git a/doc/src/declarative/modules.qdoc b/doc/src/declarative/modules.qdoc
index 53de32c..13658d8 100644
--- a/doc/src/declarative/modules.qdoc
+++ b/doc/src/declarative/modules.qdoc
@@ -42,125 +42,106 @@
 /*!
 \page qdeclarativemodules.html
 \title Modules
+\section1 QML Modules
 
-A \bold module is a collection of QML types.
+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
+upgradability of the modules.
 
-To use types from a module it must be imported using the \c import statement. Successive
-import statements override earlier import statements, however, since imports have version
-qualifiers, changes in modules do not alter the semantics of imports.
+There are two types of modules:
+location modules (defined by a URL),
+and
+installed modules (defined by a URI).
 
-\section1 Importing Types Defined in C++
-
-Types \link adding-types defined in C++\endlink can be from types your application defines, standard QML types,
-or types defined in plugins. To use any such types, you must import
-the module defining them.  For example, to use types from Qt, import it:
+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:
 
 \code
-import Qt 4.6
+import "https://qml.nokia.com/qml/example" 1.0
+import "https://qml.nokia.com/qml/example" as NokiaExample
+import "mymodule" 1.0
+import "mymodule"
 \endcode
 
-This makes available all types in Qt that were available in Qt 4.6, regardless of the
-actual version of Qt executing the QML. So even if Qt 4.7 adds a type that would conflict
-with a type you defined while using 4.6, that type is not imported, so there is no conflict.
-
-Types defined by plugins are made using QDeclarativeExtensionPlugin.  Installed plugins and QML files
-can both contribute types to the same module.
-
-
-\section1 Importing Types Defined in QML
-
-When importing types \link components defined using QML\endlink, the syntax depends
-on whether or not the types are installed on the system.
-
-
-\section2 Installed QML Files
-
-To import types defined in QML files that are installed on the system running the
-QML, a URI import is used:
-
-\code
-import com.nokia.Example 1.0
-\endcode
-
-Files imported in this way are found on the paths added by QDeclarativeEngine::addImportPath(),
-which by default only inludes \c $QTDIR/qml, so the above would make available those types
-defined in \c $QTDIR/qml/com/nokia/Example which are specified as being in version 1.0.
-Installed plugins and QML files can both contribute types to the same module.
-
-The specification of types to versions is given by a special file, \c qmldir which must
-exist in the module directory. The syntax is described below.
-
-The \c -L option to the \l {qmlviewer}{viewer} application also adds paths to the import path.
-
-
-\section2 Local QML Files
-
-To import types defined in QML files in directories relative to the file importing them,
-a quoted import directory is used:
+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:
 
 \code
-import "path"
+import com.nokia.qml.mymodule 1.0
+import com.nokia.qml.mymodule as MyModule
 \endcode
 
-This allows all components defined in the directory \c path to be used in
-the component where this statement appears.
 
-In this case, and only this case, it is not necessary for the module directory to include
-a \c qmldir file, nor is it necessary to provide a version qualifier. The basis of this is
-that the files in the subdirectory are assumed to be packaged with the importer, and therefore
-they form a single versioned unit.
+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.
 
+\seciont2 The Import Path
 
-\section2 Remote QML Files
-
-To import types defined in QML file at arbitrary network locations, a quoted absolute URL is used:
-
-\code
-import "http://url/.../" 1.0
-\endcode
-
-This works the same as for relative directory imports, except that the target location \e must
-include a \c qmldir file, and a version qualifier must be given.
+Installed modules are searched for on the import path.
+The \c -L option to the \l {Qt Declarative UI Runtime}{qml} runtime adds paths to the import path.
 
+From C++, the path is available via \l QDeclarativeEngine::importPathList() and can be prepended to
+using \l QDeclarativeEngine::addImportPath().
 
 \section2 The \c qmldir File
 
-Directories of installed files and remote content must include 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:
+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:
 
 \code
 # <Comment>
-<TypeName> <InitialVersion> <File>
+<TypeName> [<InitialVersion>] <File>
+internal <Name> <File>
+plugin <Name> [<Path>]
 \endcode
 
-<TypeName> is the type being made available; <InitialVersion> is a version
-number like \c 4.0; <File> is the (relative)
-file name of the QML file defining the type.
+# <Comment> lines are ignored, and can be used for comments.
 
-The same type can be provided by different files in different versions, in which
-case later earlier versions (eg. 1.2) must precede earlier versions (eg. 1.0),
-since the \e first name-version match is used.
+<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. 
 
 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.
-If the module is imported from a remote location, those files must nevertheless be listed in
-the \c qmldir file. Internal files can be marked with the \c internal keyword, to ensure
-they are not visible outside the module:
+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:
 
 \code
 internal <TypeName> <File>
 \endcode
 
-Installed and remote files \e must be referred to by version information described above,
+\c plugin <Name> [<Path>] lines are used to add \l{QDeclarativeExtensionPlugin}{QML C++ plugins}
+to the module. <Name> is the
+name of the library. <Path> is an optional argument specifying the full path to the directory
+containing the plugin file; if it is omitted then the directory is assumed to be the same as
+the directory of the \c qmldir file. Note that <Name> is not usually 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. 
+
+The same type can be provided by different files in different versions, in which
+case later earlier 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.
+
+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
-use those identifiers.
-
+provide those identifiers.
 
-\section1 Namespaces - Named Imports
+\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
@@ -185,10 +166,16 @@ modules can be imported into the global namespace:
 import Qt 4.6 as Nokia
 import Ovi 1.0 as Nokia
 \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
+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.
+
 */
 
 /*
 
-See original requirement QT-558.
+Original requirement is QT-558.
 
 */
diff --git a/doc/src/declarative/network.qdoc b/doc/src/declarative/network.qdoc
index e642257..f1d4db1 100644
--- a/doc/src/declarative/network.qdoc
+++ b/doc/src/declarative/network.qdoc
@@ -69,7 +69,7 @@ Network transparency is supported throughout QML, for example:
 \o WebViews - the \c url property of WebView (obviously!)
 \endlist
 
-Even QML types themselves can be on the network - if \l qmlviewer is used to load
+Even QML types themselves can be on the network - if the \l {Qt Declarative UI Runtime}{qml} tool is used to load
 \tt http://example.com/mystuff/Hello.qml and that content refers to a type "World", this
 will load from \tt http://example.com/mystuff/World.qml just as it would for a local file.
 Any other resources that \tt Hello.qml referred to, usually by a relative URL, would
@@ -131,7 +131,7 @@ See the \tt demos/declarative/flickr for a real demonstration of this.
 All network access from QML is managed by a QNetworkAccessManager set on the QDeclarativeEngine which executes the QML.
 By default, this is an unmodified Qt QNetworkAccessManager. You may set a different manager using
 QDeclarativeEngine::setNetworkAccessManager() as appropriate for the policies of your application.
-For example, the \l qmlviewer tool sets a new QNetworkAccessManager which
+For example, the \l {Qt Declarative UI Runtime}{qml} tool sets a new QNetworkAccessManager which
 trusts HTTP Expiry headers to avoid network cache checks, allows HTTP Pipelining, adds a persistent HTTP CookieJar,
 a simple disk cache, and supports proxy settings.
 
diff --git a/doc/src/declarative/qdeclarativedebugging.qdoc b/doc/src/declarative/qdeclarativedebugging.qdoc
index 3ef9ce7..e409c3e 100644
--- a/doc/src/declarative/qdeclarativedebugging.qdoc
+++ b/doc/src/declarative/qdeclarativedebugging.qdoc
@@ -60,7 +60,7 @@ Rectangle {
 \section1 Debugging Transitions
 
 When a transition doesn't look quite right, it can be helpful to view it in slow
-motion to see what is happening more clearly. \l {qmlviewer} provides a 
+motion to see what is happening more clearly. The \l {Qt Declarative UI Runtime}{qml} tool provides a 
 "Slow Down Animations" menu option to facilitate this.
 
 
@@ -108,10 +108,10 @@ To start the debugger, open a QML project and click the "QML Inspect" mode, then
 \section2 Standalone qmldebugger tool
 
 To run the standalone \c qmldebugger tool, set an environment variable \c QML_DEBUG_SERVER_PORT
-to an available port number and run the \c qmlviewer. For example:
+to an available port number and run the \l {Qt Declarative UI Runtime}{qml} tool. For example:
 
 \code
-    QML_DEBUG_SERVER_PORT=3768 qmlviewer myqmlfile.qml
+    QML_DEBUG_SERVER_PORT=3768 qml myqmlfile.qml
 \endcode
 
 Then in another process, start the \c qmldebugger tool, enter the port number into the corresponding spinbox
diff --git a/doc/src/declarative/qdeclarativei18n.qdoc b/doc/src/declarative/qdeclarativei18n.qdoc
index 9c10a46..598c567 100644
--- a/doc/src/declarative/qdeclarativei18n.qdoc
+++ b/doc/src/declarative/qdeclarativei18n.qdoc
@@ -63,7 +63,7 @@ capabilities are described more fully in:
 \o \l {Qt Linguist Manual}
 \endlist
 
-You can test a translation in \l {qmlviewer} using the -translation option.
+You can test a translation with the \l {Qt Declarative UI Runtime}{qml} tool using the -translation option.
 
 \section1 Example
 
@@ -86,10 +86,10 @@ lupdate hello.qml -ts hello.ts
 \endcode
 
 Then we open \c hello.ts in \l{Qt Linguist Manual} {Linguist}, provide
-a translation and create the release file \c hello.qm.
+a translation and create the release file \c hello.qml.
 
-Finally, we can test the translation in qmlviewer:
+Finally, we can test the translation:
 \code
-qmlviewer -translation hello.qm hello.qml
+qml -translation hello.qm hello.qml
 \endcode
 */
diff --git a/doc/src/declarative/qmlruntime.qdoc b/doc/src/declarative/qmlruntime.qdoc
index 6d3e109..8bb3ec7 100644
--- a/doc/src/declarative/qmlruntime.qdoc
+++ b/doc/src/declarative/qmlruntime.qdoc
@@ -41,32 +41,90 @@
 
 /*!
     \page qmlruntime.html
-    \title Qt Declarative UI Viewer (qmlviewer)
+    \title Qt Declarative UI Runtime
+    \keyword qml runtime
     \ingroup qttools
-    \keyword qmlviewer
 
-    This page documents the \e{Declarative UI Viewer} for the Qt GUI
-    toolkit. The \c qmlviewer reads a declarative user interface definition
+    This page documents the \e{Declarative UI Runtime} for the Qt GUI
+    toolkit, and the \c qml executable which can be used to run apps
+    written for the runtime. The \c qml executable reads a declarative user interface definition
     (\c .qml) file and displays the user interface it describes.
 
-    qmlviewer is a development tool.  It is not intended to be
-    installed in a production environment.
+    QML is a runtime, as you can run plain qml files which pull in their required modules.
+    To run apps with the QML runtime, you can either start the runtime
+    from your on application (using a QDeclarativeView) or with the simple \c qml application.
+    The \c qml application can be
+    installed in a production environment, assuming that it is not already
+    present in the system. It is generally packaged alongside Qt.
 
-    \section1 Options
+    To deploy an application using the QML runtime, you have two options:
 
-    When run with the \c -help option, qmlviewer shows available options.
+    \list
+    \o Write your own Qt application including a QDeclarative view and deploy it the same as
+    any other Qt application (not discussed further on this page), or
+    \o Write a main QML file for your application, and run your application using the included \c qml tool.
+    \endlist
 
-    \section1 Dummy Data
+    To run an application with the \c qml tool, pass the filename as an argument:
 
-    One use of qmlviewer is to allow QML files to be viewed stand-alone,
-    rather than being loaded from within a Qt program. Qt applications will
-    usually bind objects and properties into the execution context before
-    running the QML. To stand-in for such bindings, you can provide dummy
-    data: create a directory called "dummydata" in the same directory as
+    \code
+    qml myQmlFile.qml
+    \endcode
+    
+    Deploying a QML application via the \c qml executable allows for QML only deployments, but can also
+    include custom C++ modules just as easily. Below is an example of how you might structure
+    a complex application deployed via the qml runtime, it is a listing of the files that would
+    be included in the deployment package.
+
+    \code
+    MyApp.qml
+    MyAppCore/qmldir
+    MyAppCore/libMyAppCore.so
+    MyAppCore/MyAppCore.dll
+    MyAppCore/AnAppElement.qml
+    MyAppCore/AnotherElement.qml
+    MyAppCore/images/Logo.png
+    OtherModule/qmldir
+    OtherModule/OtherElement.qml
+    \endcode
+
+    Note that this example is for deploying the example to both windows and linux. You will still need to compile the C++
+    modules for each target platform, but you can deploy multiple versions of the modules across platforms with different naming conventions,
+    as the appropriate module file is chosen based on platform naming conventions. The C++ 
+    modules must contain a QDeclarativeExtentionPlugin subclass.
+
+    The application would be executed either with your own application, the command 'qml MyApp.qml' or by 
+    opening the qml file if your system has the \c qml executable registered as the handler for qml files. The MyApp.qml file would have access
+    to all of the deployed types using the import statements such as the following:
+
+    \code
+    import "MyAppCore"
+    import "OtherModule" 1.0 as Other
+    \endcode
+    
+    \section1 \c qml application functionality
+    The \c qml application implements some additional functionality to help it serve the role of a launcher
+    for myriad applications. If you implement your own launcher application, you may also wish to reimplement
+    some or all of this functionality. However, much of this functionality is intended to aid the prototyping of
+    qml applications and may not be necessary for a deployed application.
+
+    \section2 Options
+
+    When run with the \c -help option, qml shows available options.
+
+    \section2 Dummy Data
+
+    The secondary use of the qml runtime is to allow QML files to be viewed with
+    dummy data. This is useful when prototyping the UI, as the dummy data can
+    be later replaced with actual data and bindings from a C++ plugin. 
+    To provide dummy data: create a directory called "dummydata" in the same directory as
     the target QML file and create files there with the "qml" extension.
     All such files will be loaded as QML objects and bound to the root
     context as a property with the name of the file (without ".qml").
 
+    To replace this with real data, you simply bind the real object to 
+    the root context in C++.
+
     For example, if the Qt application has a "clock.time" property
     that is a qreal from 0 to 86400 representing the number of seconds since
     midnight, dummy data for this could be provided by \c dummydata/clock.qml:
@@ -76,9 +134,9 @@
     Any QML can be used in the dummy data files. You could even animate the
     fictional data!
 
-    \section1 Screen Orientation
+    \section2 Screen Orientation
 
-    A special piece of dummy data which is integrated into the viewer is
+    A special piece of dummy data which is integrated into the runtime is
     a simple orientation property. The orientation can be set via the
     settings menu in the application, or by pressing Ctrl+T to toggle it.
 
@@ -91,9 +149,13 @@
     import QDeclarativeViewer 1.0 as QDeclarativeViewer
     
     Item {
-        QDeclarativeViewer.Screen { id: qmlviewerScreen }
-        state: (qmlviewerScreen.orientation == QDeclarativeViewer.Screen.Landscape) ? 'landscape' : ''
+        QDeclarativeViewer.Screen { id: screen }
+        state: (screen.orientation == QDeclarativeViewer.Screen.Landscape) ? 'landscape' : ''
     }
 \endcode
 
+    This allows your application to respond to the orientation of the screen changing. The runtime
+    will automatically update this on some platforms (currently the N900 only) to match the physical
+    screen's orientation. On other plaforms orientation changes will only happen when explictly asked for.
+
 */
diff --git a/doc/src/declarative/scope.qdoc b/doc/src/declarative/scope.qdoc
index c588b45..964f7d5 100644
--- a/doc/src/declarative/scope.qdoc
+++ b/doc/src/declarative/scope.qdoc
@@ -160,7 +160,7 @@ Bindings have access to the scope object's properties without qualification.
 In the previous example, the binding accesses the \l Item's \c parent property
 directly, without needing any form of object prefix.  QML introduces a more 
 structured, object-oriented approach to JavaScript, and consequently does not 
-require (although it does support) use of the implicit \c this property.
+require the use of the JavaScript \c this property.
 
 Care must be used when accessing \l {Attached Properties} from bindings due
 to their interaction with the scope object.  Conceptually attached properties
diff --git a/doc/src/declarative/tutorial.qdoc b/doc/src/declarative/tutorial.qdoc
index 310b776..66de741 100644
--- a/doc/src/declarative/tutorial.qdoc
+++ b/doc/src/declarative/tutorial.qdoc
@@ -114,11 +114,11 @@ In this case, we specify that our text element should be horizontally centered i
 
 \section2 Viewing the example
 
-To view what you have created, run the qmlviewer (located in the \c bin directory) with your filename as the first argument.
+To view what you have created, run the \l{Qt Declarative UI Runtime}{qml} tool (located in the \c bin directory) with your filename as the first argument.
 For example, to run the provided completed Tutorial 1 example from the install location, you would type:
 
 \code
-bin/qmlviewer $QTDIR/examples/declarative/tutorials/helloworld/tutorial1.qml
+bin/qml $QTDIR/examples/declarative/tutorials/helloworld/tutorial1.qml
 \endcode
 */
 
diff --git a/doc/src/development/qmake-manual.qdoc b/doc/src/development/qmake-manual.qdoc
index 8cb8705..688122b 100644
--- a/doc/src/development/qmake-manual.qdoc
+++ b/doc/src/development/qmake-manual.qdoc
@@ -1425,12 +1425,20 @@ is the application private directory on the drive it is installed to.
     attention that also other statements stay valid. For example if you
     override languages statement, you must override also package-header
     statement and all other statements which are language specific.
+
+    On the Symbian platform, the \c default_deployment item specifies
+    default platform and package dependencies. Those dependencies can be
+    selectively disabled if alternative dependencies need to be defined
+    - e.g. if a specific device is required to run the application or
+    more languages need to be supported by the package file. The supported
+    \c default_deployment rules that can be disabled are:
     
-    On the Symbian platform, the \c default_deployment item specifies 
-    default platform dependencies. It can be overwritten if a more 
-    restrictive set is needed - e.g. if a specific
-    device is required to run the application.
-    
+    \list
+    \o pkg_depends_qt
+    \o pkg_depends_webkit
+    \o pkg_platform_dependencies
+    \endlist
+
     For example:
     
     \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 141
diff --git a/doc/src/frameworks-technologies/activeqt.qdoc b/doc/src/frameworks-technologies/activeqt.qdoc
index e24959d..b752122 100644
--- a/doc/src/frameworks-technologies/activeqt.qdoc
+++ b/doc/src/frameworks-technologies/activeqt.qdoc
@@ -57,6 +57,7 @@
     \brief An overview of Qt's ActiveX and COM integration on Windows.
 
     \ingroup platform-specific
+    \ingroup frameworks-technologies
     \keyword ActiveQt
 
     Qt's ActiveX and COM support allows Qt for Windows developers to:
@@ -69,19 +70,26 @@
     controls.
     \endlist
 
+    For more information about using ActiveX with Qt, see
+    \l{Building ActiveX servers and controls with Qt}.
+
     The ActiveQt framework consists of two modules:
 
     \list
-    \o The \l QAxContainer module is a static
-       library implementing QObject and QWidget subclasses, QAxObject and
-       QAxWidget, that act as containers for COM objects and ActiveX
-       controls.
-    \o The \l QAxServer module is a static library that implements
+    \o The \l{Using ActiveX controls and COM objects in Qt}{QAxContainer}
+       module is a static library implementing QObject and QWidget subclasses,
+       QAxObject and QAxWidget, that act as containers for COM objects and
+       ActiveX controls.
+    \o The \l{Building ActiveX servers and controls with Qt}{QAxServer}
+       module is a static library that implements
        functionality for in-process and executable COM servers. This
        module provides the QAxAggregated, QAxBindable and QAxFactory
        classes.
     \endlist
 
+    A set of \l{Tools for ActiveQt}{tools} is provided to simplify the
+    developing and building of Qt projects that use ActiveX.
+
     To build the static libraries, change into the \c activeqt directory 
     (usually \c QTDIR/src/activeqt), and run \c qmake and your make
     tool in both the \c container and the \c control subdirectory.
diff --git a/doc/src/modules.qdoc b/doc/src/modules.qdoc
index 76a52b4..8731d57 100644
--- a/doc/src/modules.qdoc
+++ b/doc/src/modules.qdoc
@@ -493,6 +493,14 @@
 
     \snippet doc/src/snippets/code/doc_src_qtxmlpatterns.qdoc 1
 
+    \section1 Further Reading
+
+    General overviews of XQuery and XSchema can be found in the
+    \l{Using XML Technologies} document.
+
+    An introduction to the XQuery language can be found in
+    \l{A Short Path to XQuery}.
+
     \section1 License Information
 
     The XML Schema implementation provided by this module contains the \c xml.xsd file
@@ -810,6 +818,8 @@
     \brief The QAxContainer module is a Windows-only extension for
     accessing ActiveX controls and COM objects.
 
+    QAxServer is part of the \l{ActiveQt Framework}.
+
     \section1 License Information
 
     The QAxContainer module is not covered by the \l{GNU General Public License (GPL)},
@@ -860,6 +870,8 @@
     \brief The QAxServer module is a Windows-only static library that
     you can use to turn a standard Qt binary into a COM server. 
 
+    QAxServer is part of the \l{ActiveQt Framework}.
+
     \section1 License Information
 
     The QAxContainer module is not covered by the \l{GNU General Public License (GPL)},
diff --git a/doc/src/snippets/code/doc_src_deployment.qdoc b/doc/src/snippets/code/doc_src_deployment.qdoc
index 3b0cda1..48e9ac6 100644
--- a/doc/src/snippets/code/doc_src_deployment.qdoc
+++ b/doc/src/snippets/code/doc_src_deployment.qdoc
@@ -463,7 +463,8 @@ vendorinfo = \
     "%{\"Example Localized Vendor\"}" \
     ":\"Example Vendor\""
 
-default_deployment.pkg_prerules = vendorinfo
+my_deployment.pkg_prerules = vendorinfo
+DEPLOYMENT += my_deployment
 //! [56]
 
 //! [57]
@@ -471,7 +472,9 @@ supported_platforms = \
     "; This demo only supports S60 5.0" \
     "[0x1028315F],0,0,0,{\"S60ProductID\"}"
 
-default_deployment.pkg_prerules += supported_platforms
+default_deployment.pkg_prerules -= pkg_platform_dependencies
+my_deployment.pkg_prerules += supported_platforms
+DEPLOYMENT += my_deployment
 //! [57]
 
 //! [58]
diff --git a/doc/src/snippets/code/doc_src_qmake-manual.qdoc b/doc/src/snippets/code/doc_src_qmake-manual.qdoc
index 36676ae..d9e5d3c 100644
--- a/doc/src/snippets/code/doc_src_qmake-manual.qdoc
+++ b/doc/src/snippets/code/doc_src_qmake-manual.qdoc
@@ -933,7 +933,9 @@ DEPLOYMENT += somelib justdep
 //! [140]
 
 //! [141]
-default_deployment.pkg_prerules = "[0x11223344],0,0,0,{\"SomeSpecificDeviceID\"}"
+default_deployment.pkg_prerules -= pkg_platform_dependencies
+my_deployment.pkg_prerules = "[0x11223344],0,0,0,{\"SomeSpecificDeviceID\"}"
+DEPLOYMENT += my_deployment
 //! [141]
 
 //! [142]