Docs: 6.2 Release review

Removed notes related to minor Qt5 changes.
Spelling and grammar correction.
Utilized notes and warnings formatting in places for clarity.
Updated the name of the online qdocconf file.
Used grouping to create the important topics list.
Removed qt 5 to qt 5 migration guides from important topics.

Task-number: QTBUG-97120
Pick-to: 6.2
Change-Id: Ide5354e987c5175a08030cf32d78b38bae68e53e
Reviewed-by: Robert Griebl <robert.griebl@qt.io>

1 files changed, 16 insertions, 8 deletions

diff --git a/doc/intents.qdoc b/doc/intents.qdoc
index eb825cf8..aa16f769 100644
--- a/doc/intents.qdoc
+++ b/doc/intents.qdoc
@@ -28,7 +28,10 @@
 /*!
 
 \page intents.html
+\ingroup qtappman
+\ingroup qtappman-highlights
 \title Intents
+\brief Discusses the application manager's intent system and its API.
 
 Much like the intent concept used on mobile operating systems, the application manager's intent
 system is built around the idea of having a light weight inter-process communication (IPC)
@@ -43,21 +46,24 @@ system to display an image file: if the system has an image viewer application i
 registered itself for handling the \c showImage intent, then any application could display image
 files without knowing any specifics of the image viewer application.
 
-
 The \l{https://developer.android.com/guide/components/intents-filters}{Android documentation} also
 has a nice introduction to this concept.
 
+\section1 The Application Manager's Approach to Intents
 The application manager's approach to intents is much simpler: although it (still) lacks a few
-features compared to other solutions (e.g. support for binary data or system broadcasts), it also
-comes with a very simple and straight forward API.
+features compared to other solutions. For example, support for binary data or system broadcasts.
+However, compared to other solutions, it comes with a very simple and straight forward API.
 
 \note While mobile operating systems provide you with both the intent \b mechanism as well as a
 description of all the defined \b{intent APIs}, the application manager is only providing the
 mechanism. This is in line with the philosophy used in other modules within the application
 manager, where the System UI is responsible for defining the system's interface and behavior.
 
+\section1 Intents Terminology
+
 Here is some terminology to make it easier to understand the difference between all the IDs
 involved in an intent request:
+
 \list
 \li the \c intentId: the name or class of an intent. In complex systems it makes sense to use
     reverse-DNS notation here, e.g. \c io.qt.openUrl.
@@ -73,10 +79,12 @@ involved in an intent request:
 \endlist
 
 Arbitrary data can be attached to an intent request (see IntentClient::sendIntentRequest) and to an
-intent request reply (see IntentRequest::sendReply). Please be aware that this data needs to be
-first serialized from JavaScript objects to the underlying IPC transport and then deserialized back
-to a JavaScript object on the receiving side. Restricting the types used within the parameters and
-result object to JSON types is strongly advised.
+intent request reply (see IntentRequest::sendReply).
+
+\warning This data needs to be first serialized from JavaScript objects to the
+underlying IPC transport and then de-serialized back to a JavaScript object on
+the receiving side. Restricting the types used within the parameters and result
+object to JSON types is strongly advised.
 
 
 \section1 Registering Intents
@@ -125,7 +133,7 @@ used to track the completion and possible result value of this request.
 Within the System UI you can use exactly the same mechanism to create and track intent requests.
 
 
-\section1 Disambiguating Intent Request in the System UI
+\section1 Disambiguating an Intent Request in the System UI
 
 In case an incoming intent request could potentially be handled by more than one application, the
 application manager will reach out to the System UI to disambiguate the request and pick an