Doc: review updated Enginio documentationv1.0.5

Task-number: QTBUG-39112
Change-Id: I41fa0391d68703afffb8bd67c1d9ce9f3ba4e259
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>

9 files changed, 159 insertions, 139 deletions

diff --git a/README.md b/README.md
index 37829bb..c2f3577 100644
--- a/README.md
+++ b/README.md
@@ -1,11 +1,11 @@
 # Enginio Qt Library development branch
-Client library for accessing Enginio service from Qt and QML code. 
+Client library for accessing Enginio service from Qt and QML code.
 
 # System Requirements
 * Qt 5.1 or newer
 * OpenSSL library
-  * Mac OS X: OpenSSL library should be preinstalled.
-  * Linux: Most distributions have preinstalled OpenSSL library. If yours doesn't, seach for `libssl` in package repository.
+  * Mac OS X: the OpenSSL library should be preinstalled.
+  * Linux: Most distributions have a preinstalled OpenSSL library. If yours doesn't, seach for `libssl` in the package repository.
   * Windows: Get the installer from http://slproweb.com/products/Win32OpenSSL.html (light version is enough, copy DLLs to windows system directory when asked).
 * Perl 5.10 or newer
   * Mac and Linux: Perl should be preinstalled.
@@ -16,10 +16,10 @@ Client library for accessing Enginio service from Qt and QML code.
     * Produces shared library and installs it as a globally available Qt5 module
 
 # Usage
-* In C++ applications 
+* In C++ applications
     * Use Enginio module by adding `QT += enginio` to application `.pro` file
-    * Include Enginio headers with `<Enginio/...>` (for example: `#include <Enginio/enginioclient.h>`) 
-* In QML applications 
+    * Include Enginio headers with `<Enginio/...>` (for example: `#include <Enginio/enginioclient.h>`)
+* In QML applications
     * Import Enginio components with `import Enginio 1.0`
 
 # Contributing
@@ -33,7 +33,7 @@ Client library for accessing Enginio service from Qt and QML code.
 
 # Copyright
 Copyright (C) 2013 Digia Plc and/or its subsidiary(-ies).
-Contact http://qt.digia.com/contact-us 
+Contact http://qt.digia.com/contact-us
 
 
 # License
diff --git a/doc/enginio_overview.qdoc b/doc/enginio_overview.qdoc
index 1169f72..bac8f80 100644
--- a/doc/enginio_overview.qdoc
+++ b/doc/enginio_overview.qdoc
@@ -55,13 +55,13 @@ When using Enginio (with Qt Quick or C++), the API is following a general patter
 This section gives a short, high-level overview of the concepts used throughout the library.
 
 The Qt library is a client-side library to communicate with the server at \l {http://engin.io}.
-Several backends can exist for each account on the server.
-For all communication with the server, the backend is determined by its ID.
-When shipping an application built with Enginio, the backend id will be the same for all users of that application.
+Several \e backends can exist for each account on the server.
+For all communication with the server, the \e backend is determined by its \e id.
+When shipping an application built with Enginio, the \c {backend id} will be the same for all users of that application.
 
 \section2 Objects
 
-Enginio provides several types of objects: "custom objects", "users", "user groups", "files" and more.
+Enginio provides several types of objects: \c {custom objects}, \c users, \c {user groups}, \e files, and more.
 All communication with the backend uses JSON. When writing QML, JSON can simply be written inline.
 On the C++ side, \l QJsonObject and \l QJsonValue are used.
 
@@ -100,7 +100,8 @@ For file management, the operations are slightly different.
 Files are always attached to objects and can only be referenced through them.
 The Qt library provides convenient functions to upload and download files.
 
-The entire Enginio documentation including backend and client is available here: \l{http://engin.io/documentation/}{Enginio Documentation}
+The entire Enginio documentation, including backend and client, is available here:
+\l{http://engin.io/documentation/}{Enginio Documentation}
 */
 
 /*!
@@ -146,7 +147,7 @@ To use Enginio's QML API, you have to import the library.
 import Enginio 1.0
 \endcode
 
-Initialize the \l{EnginioClientQml}{EnginioClient} with the backend id value, which can be copied from the Dashboard.
+Initialize the \l{EnginioClientQml}{EnginioClient} with the \c {backend id} value, which can be copied from the Dashboard.
 
 Go to Dashboard ⇒ Your Backend home-view ⇒ See ’Keys box’ ⇒ Copy backend id value.
 
@@ -159,7 +160,7 @@ EnginioClient {
 
 \section1 Store your first Object
 
-Now you can store an Object with Enginio. First, create an object in JSON format and fill it with data as needed.
+Now you can store an \e object with Enginio. First, create an \e object in JSON format and fill it with data as needed.
 Then call create on the client with the JSON object as a parameter.
 
 \code
@@ -200,16 +201,19 @@ To use the Enginio Qt library in your code, you have to include relevant library
  #include <Enginio/Enginio>
 \endcode
 Before making any calls to the Enginio API, the \l EnginioClient needs to be instantiated.
-They can be copied from the Dashboard.
+To do this, you will also need the \c {id} of the backend, which can be copied from the Dashboard.
 Go to the \l{https://dashboard.engin.io/}{Enginio Dashboard} and select a backend.
-Copy the backend id value.
+Copy the \c {backend id} value.
 
 \code
 QByteArray backendId("YOUR_OWN_BACKEND_ID");
 EnginioClient *client = new EnginioClient;
 client->setBackendId(backendId);
 \endcode
-For testing purposes, it is easiest to hardcode the backend id directly into application code. However, this might not be always the best choice, and sometimes it might be beneficial to put the backend configuration in a separate configuration file.
+For testing purposes, it is easiest to hardcode the \c {backend id} directly into application code.
+However, this might not be always the best choice, and sometimes it might be beneficial
+to put the backend configuration in a separate configuration file.
+
 \section1 Store your first Object
 
 Create an object in JSON format and fill in the data:
@@ -241,8 +245,8 @@ When you have successfully stored objects with Qt C++ or QML code, go to your \l
 and check the status there.
 
 \list
-\li Select the ’Objects’ view from the top navigation bar.
-\li Make sure that objects.city is selected in the type drop-down.
+\li Select the Objects view from the top navigation bar.
+\li Make sure that \gui objects.city is selected in the type drop-down.
 \li The list should now show a row for the object which was just uploaded.
 \endlist
 \image object_browser_first_city_object.png
diff --git a/examples/enginio/quick/image-gallery/doc/src/image-gallery.qdoc b/examples/enginio/quick/image-gallery/doc/src/image-gallery.qdoc
index 418a724..923b300 100644
--- a/examples/enginio/quick/image-gallery/doc/src/image-gallery.qdoc
+++ b/examples/enginio/quick/image-gallery/doc/src/image-gallery.qdoc
@@ -38,28 +38,28 @@
     \section1 Backend configuration
     The Enginio backend needs to be set up to get this example working.
 
-    Go to the Enginio Dashboard and create a new backend with 'Image Gallery' template.
+    Go to the Enginio Dashboard and create a new backend with the \c{Image Gallery} template.
 
-    The template will construct a new custom backend by executing steps:
+    The template will construct a new custom backend by executing the following steps:
     \list
-        \li Create a new object type "objects.image" (on the Object Types page).
+        \li Create a new object type \c objects.image (on the \gui{Object Types} page).
 
         Add two properties to the image object:
-        name:"name", type: "String" and name: "file", type: "Ref" with target "files".
+        \c {name:"name"}, \c {type: "String"} and \c {name: "file"}, \c {type: "Ref"} with \c {target "files"}.
 
-        \li Add a file processor by clicking the "file" property.
-        Choose "Image processor" and in "Variants" enter:
+        \li Add a file processor by clicking the \c file property.
+        Choose \gui {Image processor}, and in \gui Variants enter:
         \code
         {
             "thumbnail": { "crop":"100x100" }
         }
         \endcode
         This JSON snippet triggers the server to generate thumbnails for all uploaded images.
-        In the image gallery, the thumbnails will be used in the list view. The full image will be shown
+        In the image gallery the thumbnails will be used in the list view. The full image will be shown
         when the thumbnail is clicked.
     \endlist
 
-    Copy the backend Id from the Enginio dashboard.
+    Copy the \e {backend id} from the Enginio dashboard.
     They need to be entered into the example when it is executed for the first time.
 
     \section1 The example code
@@ -76,15 +76,15 @@
     Thus the image's thumbnail is fetched by each delegate.
     \note in a real application it might be necessary to cache the images.
 
-    The Component.onCompleted function is used to fetch the image.
+    The \c Component.onCompleted function is used to fetch the image.
     When the delegate is created, it has the JSON image object data.
-    The information needed is the "file.id" reference.
-    The "file" property was introduced in the backend setup section. Every
+    The information needed is the \c file.id reference.
+    The \c file property was introduced in the backend setup section. Every
     object (files are just objects) contains an ID that uniquely identifies the image file.
-    The image's thumbnail-url is retrieved using the ID ("variant": "thumbnail").
+    The thumbnail url of the image is retrieved using the ID ("variant": "thumbnail").
     \snippet image-gallery/image-gallery.qml image-fetch
 
-    The meta-information about each image is displayed in simple Text elements.
+    The meta-information about each image is displayed in simple \c Text elements.
     For the filename, it is possible to directly reference the \c name property as
     defined in the JSON.
     \qml
diff --git a/examples/enginio/quick/socialtodos/doc/src/socialtodos.qdoc b/examples/enginio/quick/socialtodos/doc/src/socialtodos.qdoc
index f756c90..cbea124 100644
--- a/examples/enginio/quick/socialtodos/doc/src/socialtodos.qdoc
+++ b/examples/enginio/quick/socialtodos/doc/src/socialtodos.qdoc
@@ -36,7 +36,7 @@ demonstrating the user management and access control features of Enginio.
 \section1 Introduction
 
 Social Todos is a simple todo list application with a social twist, demonstrating the user management and access control features of the Enginio service.
-The application allows the end-user to register a new user account, log in, and create and delete task lists, manage tasks on those lists and share lists with selected other users.
+The application allows the end user to register a new user account, log in, and create and delete task lists, manage tasks on those lists and share lists with selected other users.
 
 \image socialtodo-example.png
 
@@ -46,7 +46,7 @@ The application data is modeled as \e {todo items} and \e {todo lists}.
         Todo item contais a textual description of the task and a boolean status flag telling whether the task is completed or not.
     \li A \e {todo list} represents a list of tasks.
         Todo list contains zero or more todo items and each todo item belongs to just one todo list.
-        Todo lists are created by the application end-users and by default only the user who created a list can access it and its todo items.
+        Todo lists are created by the application end users. By default only the user who created a list can access it and its todo items.
         However, the creator can share the list with other users.
 \endlist
 
@@ -55,8 +55,8 @@ The Social Todos example uses the following Enginio features:
     \table
         \row
             \li \b {User management with integrated Enginio accounts}
-            \li Enables end-users to register and login.
-                End-users are identified by user-name and password.
+            \li Enables end users to register and login.
+                end users are identified by username and password.
         \row
             \li \b {Object storage}
             \li Provides shared persistent storage for task lists and tasks.
@@ -65,8 +65,7 @@ The Social Todos example uses the following Enginio features:
             \li Enforces required data structure for task lists and tasks.
         \row
             \li \b {Access control mechanisms}
-            \li Restricts access to application data so that it is available only to authenticated (logged-in) end-users.
-                End-users can see and manipulate only those task lists and tasks which they are entitled to.
+            \li Restricts access to application data so that it is available only to authenticated (logged-in) end users. End users can see and manipulate only those task lists and tasks which they are entitled to.
     \endtable
 \enddiv
 
@@ -100,11 +99,11 @@ A big part of the backend configuration is related to restricting who can create
 
         \row
             \li \b {Data access controls}
-            \li To todo lists and todo items the data access (and manipulation) is allowed only for logged-in users.
+            \li Data access (and manipulation) to todo lists and todo items is allowed only for logged-in users.
                 By default only the user who creates the todo list can access the list and its todo items.
 
                 However, the creator can share the list with other users.
-                List sharing happens by granting to selected other users right to access the list.
+                List sharing happens by granting the right to access the list to selected other users.
 
                 Access permissions are explicitly managed only for todo lists.
                 Todo items are configured to inherit permissions from the todo list which they belong to.
@@ -120,10 +119,9 @@ A big part of the backend configuration is related to restricting who can create
 \section2 1. Create 'allUsers' Usergroup
 
 Create a new usergroup \c {allUsers}.
-The usergroup will be used to restrict that only registered application end-users can store new todo lists and items to backend.
+The usergroup will be used to restrict that only registered application end users can store new todo lists and items to the backend.
 The usergroup itself is secured with suitable data access permissions.
 
-
 First create the usergroup:
 \list
     \li In the Dashboard: Select \b {Usergroups}, click \b {Add}, enter name \c {allUsers} for the usergroup, and select \b {Save}.
@@ -144,7 +142,7 @@ Then secure the usergroup by configuring suitable permission settings:
             \li
         \row
             \li \b {Object permissions}
-            \li Configure following permissions:
+            \li Configure the following permissions:
                 \list
                     \li Grant \c {read} permission to \c {all}.
                     \li Clear other permission grants.
@@ -154,14 +152,14 @@ Then secure the usergroup by configuring suitable permission settings:
                 In this case read-only access is given to everybody, so the QML application can read the \c {allUsers} data even when the application doesn't have any logged in user.
         \row
             \li \b {Member management permissions}
-            \li Configure following permissions:
+            \li Configure the following permissions:
                 \list
                     \li Grant \c {create} permission to \c {all}.
                     \li Clear other permission grants.
                 \endlist
-            \li \e {Member management permissions} control who can add new memebrs to \c {allUsers} usergroup or remove existing ones.
+            \li \e {Member management permissions} control who can add new members to the \c {allUsers} usergroup or remove existing ones.
 
-                Now member add right is given to everybody and thus the QML application can add the end-user to \c {allUsers} usergroup.
+                Now everyone can add members, and consequently the QML application can add the end user to the \c {allUsers} usergroup.
                 However, since other permissions are not granted, usergroup members can not be listed or removed.
     \endtable
 \enddiv
@@ -171,7 +169,7 @@ Then secure the usergroup by configuring suitable permission settings:
 \section2 2. Create 'todoLists' Object Type
 
 Create a new object type \c {objects.todoLists}.
-The object type defines data schema and other settings for todo list objects.
+The object type defines the data schema and other settings for todo list objects.
 
 Create the object type:
 \list
@@ -309,7 +307,7 @@ Then configure the object type with needed details:
 \section2 4. Configure 'users' Object Type
 
 Configure built-in \c {users} object type with needed security permissions.
-The \c {users} object type defines data schema and other settings for user objects, modeling application end-users.
+The \c {users} object type defines data schema and other settings for user objects, modeling application end users.
 
 \list
     \li In Dashboard: select \b {Object Types}, open \b {users} object type for editing, apply the configurations below, and finally select \b {Save} in object type editor.
@@ -384,13 +382,13 @@ The \c {usergroups} object type defines data schema and other settings for userg
                             \li No changes.
                         \endlist
                 \endlist
-            \li \e {Collection permissions} control who is able to create new \c {usergroups} objects or list existing ones.
+            \li \e {Collection permissions} control which users are able to create new \c {usergroups} objects or list existing ones.
                 In this case listing rights are granted for everyone (i.e. those are publicly readable).
-                Thus the QML application can locate \c {allUsers} usergoup in the application startup phase, even before the end-user logs-in to system.
+                Thus the QML application can locate the \c {allUsers} usergoup in the application startup phase, even before the end user logs in to the system.
                 However, since create right is not granted to anyone, new usergroups can not be created.
 
-                \e {Object permissions template} define how object level permissions will be initially set for created \c {usergroups} objects.
-                Since new usergoups will not be created dynamcally, there is no need to modify the permission template.
+                \e {Object permissions template} define how object level permissions will be set initially for the created \c {usergroups} objects.
+                Since new usergoups will not be created dynamically, there is no need to modify the permission template.
                 Note that changes made in the permissions template will effect existing \c {usergroups} objects and thus the \c {allUsers} group as well.
     \endtable
 \enddiv
diff --git a/examples/enginio/quick/todos/doc/src/todos.qdoc b/examples/enginio/quick/todos/doc/src/todos.qdoc
index bbf9b1d..7a150be 100644
--- a/examples/enginio/quick/todos/doc/src/todos.qdoc
+++ b/examples/enginio/quick/todos/doc/src/todos.qdoc
@@ -32,13 +32,13 @@
     \inmodule enginio-qml
 
     In this example a simple list of objects is displayed in a ListView.
-    Each item in the list is a "To Do" object which can be "done" or "not yet done".
+    Each item in the list is a "To Do" object which can be \e done or \e{not yet done}.
     Todos can be added and removed (when hovering with the mouse).
     \image todolist.png
 
     In this simple schema the objects will only have two properties that are added
-    to the default properties (such as creation date which always exists).
-    A string "title" and a bool "completed". The object type will be created
+    to the default properties (such as creation date, which always exists):
+    a string \c title and a bool \c completed. The object type will be created
     when a call to create, or, in this case, a call to \l{Enginio::EnginioModel::append()}{EnginioModel::append()} is made.
 
     A todo object will look like this (in JSON):
@@ -64,22 +64,23 @@
     properties of the Enginio objects are used.
     \snippet todos/todo.qml view
 
-    It is easy to add a new object to the model.
-    By using a TextField's onAccepted function, the data is
-    appended to the model. After appending the new Todo, the text gets cleared
-    so that a new Todo can be entered.
+    It is easy to add a new object to the model.  By using the \l onAccepted
+    signal handler of a \l TextField, the data is appended to the model. After appending
+    the new Todo, the text gets cleared so that a new Todo can be entered.
+
     \snippet todos/todo.qml append
 
     Inside the delegate, the data for the index is available by using the property names (\e title and \e completed).
     The \e title property is directly assigned to the text displayed on each list item. The \e completed
     boolean is used to display the item with a strikeout font and a light color.
+
     \snippet todos/todo.qml delegate-properties
 
     The \l Enginio::EnginioModel::setProperty() function is called to update the data in the Enginio backend.
 
     \snippet todos/todo.qml setProperty
 
-    The _synced property can be used to ascertain whether an item has been synced or not.
+    The \c _synced property can be used to ascertain whether an item has been synced or not.
     It is always available in the delegate, and may be used, for example, to disable the user interface
     until syncing has completed.
 
@@ -87,5 +88,6 @@
 
     Finally, a remove button is visible when hovering over an item with the mouse.
     Removal is implemented by calling \l{Enginio::EnginioModel::remove()}{EnginioModel::remove()} with the row of the item.
+
     \snippet todos/todo.qml remove
 */
diff --git a/examples/enginio/quick/users/doc/src/users.qdoc b/examples/enginio/quick/users/doc/src/users.qdoc
index 1420e60..f319c0d 100644
--- a/examples/enginio/quick/users/doc/src/users.qdoc
+++ b/examples/enginio/quick/users/doc/src/users.qdoc
@@ -28,14 +28,14 @@
 /*!
     \title Enginio QML Examples - Users
     \example users
-    \brief The Users example introduces user registration, authentication and browsing.
+    \brief The Users example introduces user registration, authentication, and browsing.
     \ingroup enginio-qml-examples
     \inmodule enginio-qml
 
     \section1 Introduction
 
     This example will demonstrate how to register and authenticate a user, and what kind of information
-    is attached to an authenticated session. This is a simple example and data access rights
+    is attached to an authenticated session. This is a simple example, and data access rights
     management is not covered here. For such information, please refer to the Social Todo example.
 
     \image users-example.png
@@ -44,71 +44,85 @@
     structures, which are the same for every backend.
 
     The example is an application that shows users registered in the backend, allows registration of
-    new users and shows how to login in separate tabs.
+    new users, and shows how to login in separate tabs.
 
     Each backend contains the "users" object type, which defines a structure
     that stores all basic data about an application's users. The collection of "users" is not
-    really different from any other collection, therefore we do not need any special
+    really different from any other collection. Therefore, we do not need any special
     methods to manipulate it. Typical data associated with a user is:
     \list
-      \li username - required name used for logging in.
-      \li email - unique email address of a user.
-      \li firstName, lastName - user's credentials (optional).
-      \li password - write-only property, this value is used during authentication.
+      \li \c username - required name used for logging in.
+      \li \c email - unique email address of a user.
+      \li \c firstName, lastName - user's credentials (optional).
+      \li \c password - write-only property, this value is used during authentication.
     \endlist
 
-    The "users" object can be extended by custom properties, too.
+    The \c users object can be extended by custom properties too.
 
     \note \e username and \e password are always required and cannot be empty.
 
-    \section1 General example structure
-    This example uses QtEnginio library together with QtQuickControls, therefore both have
+    \section1 General Example Structure
+
+    This example uses QtEnginio library together with Qt Quick Controls, therefore both have
     to be imported.
+
     \snippet users/Browse.qml imports
+
     We will also use a common \l {Enginio::EnginioClient}{EnginioClient} connection as shown here:
+
     \snippet users/users.qml client
 
-    The example is organized into separate tabs by using \l TabView. Each tab shows different
+    The example is organized into separate tabs by using \l TabView. Each tab shows a different
     functionality.
 
-    \section1 Browsing users' data
+    \section1 Browsing User Data
+
     The most convenient method to browse users is to use \l{Enginio::EnginioModel}{EnginioModel}. The model can
     automatically download all data that we need. It is sufficient to set three properties:
     \l{Enginio::EnginioModel::client}{client}, \l{Enginio::EnginioModel::query}{query}
     and \l{Enginio::EnginioModel::operation}{operation} as shown below:
+
     \snippet users/Browse.qml browse
 
     The model is used directly by TableView, in which we define data that will be shown.
+
     \snippet users/Browse.qml columns
 
-    \section1 User authentication
-    Authentication is quite easy. The only thing that needs to be done is to assign an identity, for example
+    \section1 User Authentication
+
+    Authentication is quite easy. The only thing that needs to be done is to assign an identity, for example,
     \l{EnginioOAuth2Authentication}{EnginioOAuth2Authentication} object to \l{EnginioClient::identity}{EnginioClient::identity}.
     After a while, \l{EnginioClient::authenticationState}{EnginioClient::authenticationState} will change and
     \l{EnginioClient::sessionAuthenticated}{sessionAuthenticated} or \l{EnginioClient::sessionAuthenticationError}{sessionAuthenticationError}
     will be emitted.
 
     The first thing we need to do is to create an identity object: \l{EnginioOAuth2Authentication}{EnginioOAuth2Authentication}
+
     \snippet users/Login.qml identity
 
     Then, depending on the state of the application, we assign the object to
     our enginioClient instance. There are four possible states, defined by
     \l{Enginio::AuthenticationState}. After assigning the Identity object,
-    the state changes from the initial "NotAuthenticated" to "Authenticating".
+    the state changes from the initial \c NotAuthenticated to \c Authenticating.
+
     \snippet users/Login.qml assignIdentity
 
-    Once the authentication query finishes, the state changes to "Authenticated" or
-    "AuthenticationFailure" depending on the authentication result. Null
+    Once the authentication query has finished, the state changes to \c Authenticated or
+    \c AuthenticationFailure depending on the authentication result. Null
     assignment to the \l{EnginioClient::identity}{identity} causes the session to terminate immediately:
+
     \snippet users/Login.qml assignNull
 
     For educational purposes, in the example we also show a log window with data attached to
     a session that is changing state.
+
     \snippet users/Login.qml connections
 
-    \section1 Registering a new user
-    Registration of a new user is as simple as adding a new object to the "users" collection. It can be achieved
+    \section1 Registering a New User
+
+    Registration of a new user is as simple as adding a new object to the \c users collection. It can be achieved
     by using the \l{EnginioClient::create}{create} function, as shown below:
+
     \snippet users/Register.qml create
 
     We could also use the \l{Enginio::EnginioModel::append}{EnginioModel::append} method in the browsing example
diff --git a/examples/enginio/widgets/cloudaddressbook/doc/src/cloudaddressbook.qdoc b/examples/enginio/widgets/cloudaddressbook/doc/src/cloudaddressbook.qdoc
index 8fc5b1d..2f5fbf4 100644
--- a/examples/enginio/widgets/cloudaddressbook/doc/src/cloudaddressbook.qdoc
+++ b/examples/enginio/widgets/cloudaddressbook/doc/src/cloudaddressbook.qdoc
@@ -28,26 +28,26 @@
 /*!
     \title Enginio C++ Examples - Cloud Address Book
     \example cloudaddressbook
-    \brief The Cloud Address Book example shows sorting, filtering and the full text search functionality
+    \brief The Cloud Address Book demonstrates how to use sorting, filtering, and the full text search functionality.
     \ingroup enginio-examples
     \inmodule enginio-qt
 
-    This example explains how to use the full text search feature of Enginio and how to sort and filter data
-    showed from the EnginioModel. To present that. a simple address book like application, will be created.
-    This example doesn't cover security or multi-user management, for such topics please refer
-    to Social Todo example.
+    This example explains how to use the full text search feature of Enginio, and how to sort and filter data
+    showed from the EnginioModel. A simple addressbook-like application will be created to illustrate this.
+    This example doesn't cover security or multi-user management. For such topics, please refer to the
+    Social Todo example.
 
     \image cloudaddressbook-example.png
 
     \section1 Preconditions
-    To start the example, a backend id and a backend secret have to be provided to an existing and configured
-    Enginio backend. The backend can be created using dashboard, the Cloud Address Book pre-configured backend
+    To start the example, a \e {backend id} and a \e {backend secret} have to be provided for an existing and configured
+    Enginio backend. The backend can be created using the dashboard, where the Cloud Address Book preconfigured backend
     can be chosen.
 
     \section1 Backend description
-    We recommend to use pre-configured backend, because it contain already all data and structures that are
-    needed to run this examples, but it is not difficult to create the backend from scratch too.
-    The backend should contain one custom object type "objects.addressbook" having properties:
+    We recommend to use preconfigured backend, because it contains already all data and structures that are
+    needed to run these examples, but it is not difficult to create the backend from scratch too.
+    The backend should contain one custom object type \c objects.addressbook having properties:
     \list
         \li firstName
         \li lastName
@@ -55,62 +55,64 @@
         \li phone
         \li address
     \endlist
-    All properties are of string type and have to be indexed, because only indexed properties will be searched
+    All properties are of \c string type and have to be indexed, because only indexed properties will be searched
     by the full text search.
 
     \section1 Application design
-    The application's ui mainly consist of a table showing all addresses and a text filed where a query
+    The application's ui mainly consists of a table showing all addresses and a text filed where a query
     can be typed. A user should be able to sort addresses or highlight an address containing a specified phrase.
 
     \section1 Implementation
-    From a developer point of view the application from a few simple components:
+    From a developer point of view the application consists of a few simple components:
     \list
-        \li EnginioClient which encapsulates all information that are needed to keep connection to the backend
-        \li EnginioModel which queries all addresses
-        \li QSortFilterProxy which sorts the data
-        \li QTableView which shows the data
+        \li \l EnginioClient which encapsulates all information needed to keep the connection to the backend
+        \li \l EnginioModel which queries all addresses
+        \li \l QSortFilterProxy which sorts the data
+        \li \l QTableView which shows the data
     \endlist
 
-    The first thing to be done is to construct connection to Enginio service. We need to specify backend id as well
-    as backend secret.
+    First we need to establish a connection to the Enginio service. We need to specify the \e{backend id} as well
+    as \e {backend secret}.
     \snippet cloudaddressbook/mainwindow.cpp client
 
     The second step is to create EnginioModel which queries all data from the backend. The query is quite simple,
-    it specifies an object type of which all objects needs to be returned.
+    it specifies an object type of which all objects need to be returned.
     \snippet cloudaddressbook/mainwindow.cpp model
 
-    EnginioModel can sort or filter data only initially, which means that for example a newly added
+    EnginioModel can sort or filter data only initially, which means that, for example, a newly added
     item will not be placed correctly. To solve the problem QSortFilterProxy has to be used.
     \snippet cloudaddressbook/mainwindow.cpp assignProxyModel
 
-    Now it is a time to look deeper into EngnioModel. EnginioModel should define data roles.
+    Now is a time to look deeper into EngnioModel. EnginioModel should define data roles.
     \snippet cloudaddressbook/addressbookmodel.h Roles
     \snippet cloudaddressbook/addressbookmodel.cpp Roles
 
-    and as always \l{EnginioModel::data()}{data()} \l{EnginioModel::setData()}{setData()} functions have to be overridden
-    to provide Qt::DisplayRole in the way it is needed to nicely cooperate with QTableView.
+    and as always the \l{EnginioModel::data()}{data()} and \l{EnginioModel::setData()}{setData()} functions
+    have to be overridden to provide Qt::DisplayRole in such a way as to nicely cooperate with QTableView.
     \snippet cloudaddressbook/addressbookmodel.cpp data
 
-    Usage of QTableView requires to provide columns headers, so they can be shown in the user interface
+    QTableView requires the specification of columns headers, so that they can be shown in the user interface:
     \snippet cloudaddressbook/addressbookmodel.cpp tableViewIntegration
 
     Integration of the full text search is the last step in this tutorial. The goal is to highlight items that
-    contains a given phrase. The highlighting is done by \l{EnginioModel::data()}{data()}, which returns a bold font
-    for Qt::FontRole, if an item is matching the search query. This example for simplicity assumes that matching
-    items count is not big and can be kept in a QSet, which would be recreated on each search.
+    contain a given phrase. The highlighting is done by \l{EnginioModel::data()}{data()}, which returns a bold font
+    for Qt::FontRole if an item is matching the search query. For reasons of simplicity, this example assumes that
+    the matching items count is not big and can be kept in a QSet, which would be recreated on each search.
+
+    To do a full text search, a JSON query needs to be constructed:
 
-    To do a full text search, a JSON query needs to be constructed.
     \snippet cloudaddressbook/addressbookmodel.cpp query
-    The query contains "objectTypes" property (mark 's' at the end) which is an array of all object types which
-    have to be searched. In this case, it is only one type "objects.addressbook". Next "search" property has to
-    be filed. It is an object that is required to have "phrase" property. The property is exactly the search
-    phrase that has to be found. Please mark '*' characters, without them the full text search would find
-    only full words. To avoid founding substrings, for example in on object id, which is not visible for a user
-    the search has to limit scanned property list, by "properties" array.
-
-    When the search query is constructed it is enough to call \l{EnginioClient::fullTextSearch()}{fullTextSearch()}:
+
+    The query contains \c objectTypes property (note the 's' at the end) which is an array of all object types which
+    have to be searched. In this case, it is only one type: \c objects.addressbook. Next the \c search property has to
+    be specified. It is an object that is required to have a \c phrase property, containing the phrase to search for.
+    phrase that has to be found. Please use the wildcard  \c * in the search criteria, otherwise only full words will
+    be found. To avoid substrings, for example in an \c {object id}, which is not visible for a user,
+    the search is limited to a selected array of \c {properties}.
+    When the search query is constructed, it is enough to call \l{EnginioClient::fullTextSearch()}{fullTextSearch()}:
     \snippet cloudaddressbook/addressbookmodel.cpp callSearch
-    The result will be delivered to the searchResultsArrived slot. In which from result array all objects ids
-    are gathered in \a markedItems set.
+    The result will be delivered to the \c searchResultsArrived slot. All objects ids found will be gathered in a
+    \c markedItems set.
+
     \snippet cloudaddressbook/addressbookmodel.cpp results
 */
diff --git a/examples/enginio/widgets/image-gallery-cpp/doc/src/image-gallery-cpp.qdoc b/examples/enginio/widgets/image-gallery-cpp/doc/src/image-gallery-cpp.qdoc
index 5fba310..4a5fa2b 100644
--- a/examples/enginio/widgets/image-gallery-cpp/doc/src/image-gallery-cpp.qdoc
+++ b/examples/enginio/widgets/image-gallery-cpp/doc/src/image-gallery-cpp.qdoc
@@ -36,18 +36,18 @@
     \image gallery-example.png
 
     \section1 Backend configuration
-    The Enginio backend needs to be set up in order to get this example working.
+    The \e Enginio \e backend needs to be set up in order to get this example working.
 
-    Go to the Enginio Dashboard and create a new backend with the 'Image Gallery' template.
+    Go to the \e {Enginio Dashboard} and create a new backend with the \gui {Image Gallery} template.
     The template will construct a new custom backend by executing these steps:
     \list
-        \li Create a new object type "objects.image" (on the Object Types page).
+        \li Create a new object type \c objects.image (on the \gui {Object Types} page).
 
             Add two properties to the image object:
             name:"name", type: "String" and name: "file", type: "Ref" with target "files".
 
-        \li Add a file processor by clicking the "file" property.
-            Choose "Image processor" and in "Variants" enter:
+        \li Add a file processor by clicking the \c file property.
+            Choose \gui {Image processor} and in \gui {Variants} enter:
             \code
             {
                 "thumbnail": { "crop":"100x100" }
@@ -58,15 +58,15 @@
             when the thumbnail is clicked.
     \endlist
 
-    Copy the backend Id from the Enginio dashboard and use them when requested.
+    Copy the backend id from the Enginio dashboard, and use them when requested.
 
-    \section1 The example code
+    \section1 The Example Code
 
     The example consists of three classes.
     ImageModel is a subclass of \l {EnginioModelCpp}{EnginioModel}
     that exposes the images in the \l Qt::DecorationRole for the list view.
-    In the MainWindow, a normal QListView is used to display the model contents.
-    The ImageObject is a class that takes care of the download and emits a signal
+    In the \c {MainWindow}, a normal QListView is used to display the model contents.
+    The ImageObject is a class that takes care of the download, and emits a signal
     when an image has been downloaded.
 
 
diff --git a/examples/enginio/widgets/todos-cpp/doc/src/todos-cpp.qdoc b/examples/enginio/widgets/todos-cpp/doc/src/todos-cpp.qdoc
index 6a153c2..ebbce73 100644
--- a/examples/enginio/widgets/todos-cpp/doc/src/todos-cpp.qdoc
+++ b/examples/enginio/widgets/todos-cpp/doc/src/todos-cpp.qdoc
@@ -27,7 +27,7 @@
 /*!
     \title Enginio C++ Examples - Todos
     \example todos-cpp
-    \brief The Todo example shows the \l {EnginioModelCpp}{EnginioModel} usage together with QtWigets.
+    \brief The Todo example shows how to use the \l {EnginioModelCpp}{EnginioModel} with Qt Widgets.
     \ingroup enginio-examples
     \inmodule enginio-qt
 
@@ -49,26 +49,26 @@
 }
     \endcode
 
-    The first step is to create a TodosModel which inherits \l {EnginioModelCpp}{EnginioModel}
+    The first step is to create a TodosModel which inherits \l {EnginioModelCpp}{EnginioModel},
     and defines the main roles which will be used. As we are interested in the To Do \c title
     and the \c completed information we need to define these two roles.
     \snippet todos-cpp/todosmodel.h definition
 
-    By default views (for example \l QListView) use the \l{Qt::ItemDataRole} role to display or edit the content.
+    By default, views (for example \l QListView) use the \l{Qt::ItemDataRole} role to display or edit the content.
     The newly created \l{EnginioModelCpp}{EnginioModel} is empty and defines basic roles. Most roles are created
-    dynamically, based on the json data-structure.  They have no predefined value in the \l Qt::ItemDataRole enum.
+    dynamically, based on the JSON datastructure.  They have no predefined value in the \l Qt::ItemDataRole enum.
     \l{EnginioModelCpp}{EnginioModel} automatically populates itself as soon as the
     \l{EnginioModel::query}{query} and \l{EnginioModel::client}{client} properties have been set.
     When the data is downloaded, the model resets itself, and sets up the internal data cache and roles names.
-    \l{EnginioModelCpp}{EnginioModel} guesses the role names based on heuristics and it may be wrong if not all
-    objects received from the backend have exactly the same structure, for example a property can be missing
-    in certain objects. To protect against such cases we overload \l{EnginioModel::roleNames()}{roleNames()}.
+    \l{EnginioModelCpp}{EnginioModel} guesses the role names based on heuristics. It may be wrong if not all
+    objects received from the backend have exactly the same structure. For example, a property can be missing
+    in certain objects. To protect against such cases, we overload \l{EnginioModel::roleNames()}{roleNames()}.
     Overriding \l{EnginioModel::roleNames()}{roleNames()} can also be used to match default Qt roles to the named
     ones.
 
     \snippet todos-cpp/todosmodel.cpp roleNames
 
-    In this example we map the \l Qt::DisplayRole and \l Qt::EditRole to the "title" property in the JSON.
+    In this example we map the \l Qt::DisplayRole and \l Qt::EditRole to the \c title property in the JSON.
     This way the right string is shown by default and editing works as expected.
 
     Remember to always call the base class implementation to avoid situations in which the internal cache is not in sync.
@@ -84,18 +84,18 @@
 
     \snippet todos-cpp/mainwindow.cpp client
 
-    It is used by model to connect to the Enginio backend. Next we need to construct
+    It is used by the model to connect to the Enginio backend. Next we need to construct
     and configure our model too. The configuration is based on two steps, assigning
     an \l EnginioClient instance and by creating a query.
 
     \snippet todos-cpp/mainwindow.cpp model
 
-    The model has to be assigned to a view, in our case it is a \l QListView.
+    The model has to be assigned to a view. In our case it is a \l QListView.
 
     \snippet todos-cpp/mainwindow.cpp assignModel
 
     To make the application fully functional, a way to add and remove "To Dos" is needed.
-    To do so, we need to connect correct buttons to slots for adding a new item:
+    To do so, we need to connect the correct buttons to slots for adding a new item:
 
     \snippet todos-cpp/mainwindow.cpp appendItem