Docs: 6.2 release review

Spelling and grammar check
Applied principles of Qt Documentation guidelines where applicable
Update the index page with some info from the "big picture" section from the
extending qtIF page.
Focused on the core module in this review.
Future work could include breaking the chapters in the qface  tutorial out into
pages.

Task-number: QTBUG-97118
Pick-to: 6.2
Change-Id: I3ac094f0ccafbb82995d7a4c8f3969d92db429be
Reviewed-by: Dominik Holland <dominik.holland@qt.io>

1 files changed, 28 insertions, 25 deletions

diff --git a/examples/interfaceframework/qface-climate/doc/src/qface-climate.qdoc b/examples/interfaceframework/qface-climate/doc/src/qface-climate.qdoc
index 7cfc0ac1..cac8f585 100644
--- a/examples/interfaceframework/qface-climate/doc/src/qface-climate.qdoc
+++ b/examples/interfaceframework/qface-climate/doc/src/qface-climate.qdoc
@@ -36,19 +36,20 @@
 
 \section1 Introduction
 
-This example shows you how you can use the Qt Interface Framework Generator to build a new component. Based on a
-single QFace IDL file, the example generates:
+This example shows you how you can use the Qt Interface Framework Generator to
+build a new component. Based on a single QFace Interface Definition Language
+(IDL) file, the example generates:
 
 \list
-    \li a shared library with the frontend code
-    \li a backend simulator plugin
+    \li a shared library with the front end code
+    \li a back end simulator plugin
     \li a demo application that shows the values in the current module
 \endlist
 
 \section1 The IDL File
 
-The IDL file used in this example represents a simplified climate control interface that contains a
-single interface and some enumerated types.
+The IDL file used in this example represents a simplified climate control
+interface that contains a single interface and some enumerated types.
 
 Let's take a look at a minimal version of the same QFace IDL file:
 
@@ -179,7 +180,7 @@ Here's an overview of all the annotations used in this example and what they do:
             instances.
 \endtable
 
-In addition to the IDL file, a YAML file with the same basename is used to add extra
+In addition to the IDL file, a YAML file with the same base name is used to add extra
 configurations. These configurations may also be added directly into the IDL file, but we choose
 to keep them separate for readability.
 
@@ -201,11 +202,11 @@ Some of these extra configurations are highlighted below:
                 config_simulator:
                     default: RecirculationMode.RecirculationOff
             \endcode
-        \li Specifies the default value assigned to a property in the simulator backend plugin.
+        \li Specifies the default value assigned to a property in the simulator back end plugin.
 \endtable
 
 
-\section1 Frontend Library
+\section1 Front End Library
 
 Now we want to use the Interface Framework Generator to generate a shared library that contains a C++
 implementation of our module and its interface.
@@ -248,12 +249,13 @@ additional code to report errors:
 The other part of the project file is a normal library setup which should work on Linux, macOS,
 and Windows.
 
-\section1 Backend Simulator Plugin
+\section1 Back End Simulator Plugin
 
-Since the \c frontend library uses the \l {Dynamic Backend System}, we need a corresponding
-\c backend plugin, for the library to provide some functionality. To generate a mock version of
-the backend plugin called "Simulator Backend", you can use the \c backend_simulator template from
-the same IDL file as the \c frontend library. The build system integration works in the same way, but it
+Since the \c{front end} library uses the \l {Dynamic Backend System}, we need a corresponding
+\c{back end} plugin, for the library to provide some functionality. To generate a mock version of
+the back end plugin called "Simulator Backend", you can use the \c backend_simulator template from
+the same IDL file as the \c{front end} library uses the \l {Dynamic Backend System}, we need a corresponding
+\c{back end} plugin, fo library. The build system integration works in the same way, but it
 uses a different generation template.
 
 \e CMake:
@@ -274,21 +276,21 @@ For the plugin to compile correctly it needs to get the backend interface header
 created library. However, this header is not part of our source tree but the build tree, because it
 is also generated. We provide this header by adding it to the include path using the following code:
 
-\e CMake:
-
-\snippet interfaceframework/qface-climate/backend_simulator/CMakeLists.txt 1
-
 \e qmake:
 
 \snippet interfaceframework/qface-climate/backend_simulator/backend_simulator.pro 1
 
+\e CMake:
+
+\snippet interfaceframework/qface-climate/backend_simulator/CMakeLists.txt 1
+
 The \c backend_simulator template makes use of the \b @config_simulator annotations explained
-\l{Annotations}{above}. This means that the generated backend provides the default values defined
+\l{Annotations}{above}. This means that the generated back end provides the default values defined
 in the annotations and checks the boundaries of new values using the \c minimum/maximum or \c range
 annotations.
 
-Using the \c zones annotations, the generated backend provides individual values for every zone
-and communicates the available zones to the frontend library. For more information, see the
+Using the \c zones annotations, the generated back end provides individual values for every zone
+and communicates the available zones to the front end library. For more information, see the
 \l {Climate Control QML Example}.
 
 \section1 Demo Application
@@ -296,9 +298,9 @@ and communicates the available zones to the frontend library. For more informati
 The demo application presents a simple QML interface with all the properties of the generated
 interface.
 
-Since we do not provide a QML plugin, the application needs to link to the generated frontend
+Since we do not provide a QML plugin, the application needs to link to the generated front end
 library and call the \c {ClimateModule::registerTypes} and \c {ClimateModule::registerQmlTypes}
-methods that are generated in the module singleton to register all autogenerated interfaces and
+methods that are generated in the module singleton to register all auto-generated interfaces and
 types with the QML engine.
 
 In our QML application, we still need to import the module using the same module URI used
@@ -307,12 +309,13 @@ in the IDL file. Afterwards, the interface can be instantiated like a regular QM
 \snippet interfaceframework/qface-climate/demo/main.qml 0
 \dots 0
 
-Our application doesn't know about our backend plugin, so, we need to put this plugin in the folder
+Our application doesn't know about our back end plugin, so, we need to put this plugin in the folder
 where our application looks for plugins. By default, Qt looks in the \b plugins folder within its
 installation directory or in the application's current working directory. For QtInterfaceFramework plugins to be
 found, they need to be placed within a \b interfaceframework sub-folder.
 
-To make sure this is done automatically, we add the following line to our backend build system file:
+To make sure this is done automatically, we add the following line to our back end
+build system file:
 
 \e CMake: