Doc fixes

4 files changed, 32 insertions, 20 deletions

diff --git a/doc/src/declarative/advtutorial.qdoc b/doc/src/declarative/advtutorial.qdoc
index 4d3bfa8..4807fd2 100644
--- a/doc/src/declarative/advtutorial.qdoc
+++ b/doc/src/declarative/advtutorial.qdoc
@@ -175,12 +175,10 @@ and moves the new block to its position on the game canvas. This involves severa
 \list
 \o \l {createComponent(url file)}{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.
-   (If a component is loaded remotely - over HTTP for example - then we would have to wait for the
-   component to finish loading before calling \c createObject()).
 \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 in the blocks array for future reference.
+   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
@@ -242,17 +240,17 @@ As this is a tutorial about QML, not game design, we will only discuss \c handle
 
 \section3 Enabling mouse click interaction
 
-To make it easier for the JavaScript code to interface with the QML elements, we have added an Item called \c gameCanvas to \c samegame.qml. It replaces the background as the item which contains the blocks, and accepts mouse input from the user.  Here is the item code:
+To make it easier for the JavaScript code to interface with the QML elements, we have added an Item called \c gameCanvas to \c samegame.qml. It replaces the background as the item which contains the blocks. It also accepts mouse input from the user.  Here is the item code:
 
 \snippet declarative/tutorials/samegame/samegame3/samegame.qml 1
 
-The \c gameCanvas item is the exact size of the board, and has a \c score property and a \l MouseArea for input.
+The \c gameCanvas item is the exact size of the board, and has a \c score property and a \l MouseArea to handle mouse clicks.
 The blocks are now created as its children, and its dimensions are used to determine the board size so that
 the application scales to the available screen size.
-Since its size is bound to a multiple of \c blockSize, \c blockSize needs to be moved out of \c samegame.js and into \c samegame.qml as a QML property.
+Since its size is bound to a multiple of \c blockSize, \c blockSize was moved out of \c samegame.js and into \c samegame.qml as a QML property.
 Note that it can still be accessed from the script.
 
-The \l MouseArea simply calls \c{handleClick()} in \c samegame.js, which determines whether the player's click should cause any blocks to be removed, and updates \c gameCanvas.score with the current score if necessary. Here is the \c handleClick() function:
+When clicked, the \l MouseArea calls \c{handleClick()} in \c samegame.js, which determines whether the player's click should cause any blocks to be removed, and updates \c gameCanvas.score with the current score if necessary. Here is the \c handleClick() function:
 
 \snippet declarative/tutorials/samegame/samegame3/samegame.js 1
 
@@ -441,7 +439,7 @@ By following this tutorial you've seen how you can write a fully functional appl
 \o Build your application with \l {{QML Elements}}{QML elements}
 \o Add application logic \l{Integrating JavaScript}{with JavaScript code}
 \o Add animations with \l {Behavior}{Behaviors} and \l{QML States}{states}
-\o Store persistent application data using the \l{Offline Storage API} or \l XMLHttpRequest
+\o Store persistent application data using, for example, the \l{Offline Storage API} or \l XMLHttpRequest
 \endlist
 
 There is so much more to learn about QML that we haven't been able to cover in this tutorial. Check out all the
diff --git a/doc/src/declarative/javascriptblocks.qdoc b/doc/src/declarative/javascriptblocks.qdoc
index 3544bc9..5fc3938 100644
--- a/doc/src/declarative/javascriptblocks.qdoc
+++ b/doc/src/declarative/javascriptblocks.qdoc
@@ -87,11 +87,12 @@ JavaScript file.
 
 \section1 Separate JavaScript files
 
-Large blocks of JavaScript should be written in separate files.  Like element 
-types, external JavaScript files are \c {import}'ed into QML files.
+Large blocks of JavaScript should be written in separate files. These files
+can be imported into QML files using an \c import statement, in the same way
+that \l {Modules}{modules} are imported.
 
-The \c {factorial()} method used in the \l {Inline JavaScript} section could
-be refactored into an external file, and accessed like this.
+For example, the \c {factorial()} method in the above example for \l {Inline JavaScript}
+could be moved into an external file named \c factorial.js, and accessed like this:
 
 \code
 import "factorial.js" as MathFunctions
@@ -107,8 +108,8 @@ Both relative and absolute JavaScript URLs can be imported.  In the case of a
 relative URL, the location is resolved relative to the location of the 
 \l {QML Document} that contains the import.  If the script file is not accessible, 
 an error will occur.  If the JavaScript needs to be fetched from a network 
-resource, the QML document will remain in the 
-\l {QDeclarativeComponent::status()}{waiting state} until the script has been 
+resource, the QML document stays in the
+\l {QDeclarativeComponent::status()}{"Loading" status} until the script has been 
 downloaded.
 
 Imported JavaScript files are always qualified using the "as" keyword.  The 
@@ -167,9 +168,7 @@ might not have been created or some \l {Property Binding}s may not have been run
 
 The QML \l Component element provides an \e attached \c onCompleted property that
 can be used to trigger the execution of script code at startup after the
-QML environment has been completely established.
-
-The following QML code shows how to use the \c Component::onCompleted property.
+QML environment has been completely established. For example:
 
 \code
 Rectangle {
@@ -182,7 +181,7 @@ Rectangle {
 \endcode
 
 Any element in a QML file - including nested elements and nested QML component 
-instances - can use this attached property.  If there is more than one onCompleted 
+instances - can use this attached property.  If there is more than one \c onCompleted()
 handler to execute at startup, they are run sequentially in an undefined order.
 
 \section1 QML JavaScript Restrictions 
diff --git a/doc/src/declarative/qdeclarativesecurity.qdoc b/doc/src/declarative/qdeclarativesecurity.qdoc
index 56216dd..ab75a57 100644
--- a/doc/src/declarative/qdeclarativesecurity.qdoc
+++ b/doc/src/declarative/qdeclarativesecurity.qdoc
@@ -72,7 +72,7 @@ A non-exhaustive list of the ways you could shoot yourself in the foot is:
 \list
     \i Using \c import to import QML or JavaScropt you do not control. BAD
     \i Using \l Loader to import QML you do not control. BAD
-    \i Using XMLHttpRequest to load data you do not control and executing it. BAD
+    \i Using \l{XMLHttpRequest()}{XMLHttpRequest} to load data you do not control and executing it. BAD
 \endlist
 
 However, the above does not mean that you have no use for the network transparency of QML.
@@ -81,7 +81,7 @@ There are many good and useful things you \e can do:
 \list
     \i Create \l Image elements with source URLs of any online images. GOOD
     \i Use XmlListModel to present online content. GOOD
-    \i Use XMLHttpRequest to interact with online services. GOOD
+    \i Use \l{XMLHttpRequest()}{XMLHttpRequest} to interact with online services. GOOD
 \endlist
 
 The only reason this page is necessary at all is that JavaScript, when run in a \e{web browser},
diff --git a/src/declarative/util/qdeclarativelistmodel.cpp b/src/declarative/util/qdeclarativelistmodel.cpp
index 37bbb14..e3680f2 100644
--- a/src/declarative/util/qdeclarativelistmodel.cpp
+++ b/src/declarative/util/qdeclarativelistmodel.cpp
@@ -248,6 +248,20 @@ QDeclarativeListModelParser::ListInstruction *QDeclarativeListModelParser::ListM
 */
 
 
+/*
+    A ListModel internally uses either a NestedListModel or FlatListModel.
+
+    A NestedListModel can contain lists of ListElements (which
+    when retrieved from get() is accessible as a list model within the list
+    model) whereas a FlatListModel cannot.
+
+    ListModel uses a NestedListModel to begin with, and if the model is later 
+    used from a WorkerScript, it changes to use a FlatListModel instead. This
+    is because ModelNode (which abstracts the nested list model data) needs
+    access to the declarative engine and script engine, which cannot be
+    safely used from outside of the main thread.
+*/
+
 QDeclarativeListModel::QDeclarativeListModel(QObject *parent)
 : QListModelInterface(parent), m_agent(0), m_nested(new NestedListModel(this)), m_flat(0), m_isWorkerCopy(false)
 {
@@ -1351,6 +1365,7 @@ ModelObject::ModelObject()
 void ModelObject::setValue(const QByteArray &name, const QVariant &val)
 {
     _mo->setValue(name, val);
+    setProperty(name.constData(), val);
 }