Doc: Updates based on sanity checkv5.1.0-beta1

- Removed redundant qdoc pages on supported
platforms, getting source, and building from source.
- Added a module page to list the C++ classes
- Removed unnecessary \module commands in several pages
- Made a few language edits to class documentation
- Updated the index page with some introductory content
- Fixed broken links to the examples

Change-Id: Ia7bd74b383f344426814db736f7bc4cd77c13992
Reviewed-by: Laszlo Papp <lpapp@kde.org>

3 files changed, 23 insertions, 20 deletions

diff --git a/examples/serialport/doc/blockingmaster.qdoc b/examples/serialport/doc/blockingmaster.qdoc
index 40ac0702..4bf4b864 100644
--- a/examples/serialport/doc/blockingmaster.qdoc
+++ b/examples/serialport/doc/blockingmaster.qdoc
@@ -43,17 +43,17 @@
     and performed when the control returns to Qt's event loop. QSerialPort emits
     a signal when the operation is finished. For example, QSerialPort::write()
     returns immediately. When the data is sent to the serial port, QSerialPort
-    emits \l{QSerialPort::bytesWritten()}{bytesWritten()}.
+    emits \l{QIODevice::bytesWritten()}{bytesWritten()}.
 
     \li \e{The synchronous (blocking) approach.} In non-GUI and multithreaded
     applications, the \c waitFor...() functions can be called (i.e.
-    QSerialPort::waitReadyRead()) to suspend the calling thread until the
+    QSerialPort::waitForReadyRead()) to suspend the calling thread until the
     operation has completed.
 
     \endlist
 
     In this example, the synchronous approach is demonstrated. The
-    \l{terminal}{Simple Terminal} example illustrates the
+    \l{terminal}{Terminal} example illustrates the
     asynchronous approach.
 
     The purpose of this example is to demonstrate a pattern that you can use
@@ -102,7 +102,7 @@
     serial port name, timeout and request data from the member data, and then
     releasing the lock again. The case that we are protecting ourselves against
     is that \c transaction() could be called at the same time as we are fetching
-    this data. QString is \l reentrant but \e not \l{thread-safe}, and we must
+    this data. QString is reentrant but not thread-safe, and we must
     also avoid the unlikely risk of reading the serial port name from one request,
     and timeout or request data of another. And as you might have guessed,
     MasterThread can only handle one request at a time.
@@ -158,5 +158,5 @@
 
     \snippet blockingmaster/masterthread.cpp 13
 
-    \sa {Simple Terminal Example}, {Blocking Slave Example}
+    \sa {Terminal Example}, {Blocking Slave Example}
 */
diff --git a/examples/serialport/doc/blockingslave.qdoc b/examples/serialport/doc/blockingslave.qdoc
index 4b835d98..95690dcd 100644
--- a/examples/serialport/doc/blockingslave.qdoc
+++ b/examples/serialport/doc/blockingslave.qdoc
@@ -43,17 +43,18 @@
     and performed when the control returns to Qt's event loop. QSerialPort emits
     a signal when the operation is finished. For example, QSerialPort::write()
     returns immediately. When the data is sent to the serial port, QSerialPort
-    emits \l{QSerialPort::bytesWritten()}{bytesWritten()}.
+    emits \l{QIODevice::bytesWritten()}{bytesWritten()}.
 
     \li \e{The synchronous (blocking) approach.} In non-GUI and multithreaded
     applications, the \c waitFor...() functions can be called (i.e.
-    QSerialPort::waitReadyRead()) to suspend the calling thread until the
+    QSerialPort::waitForReadyRead()) to suspend the calling thread until the
     operation has completed.
 
     \endlist
 
     In this example, the synchronous approach is demonstrated. The
-    \l{slave}{Slave Example} example illustrates the asynchronous approach.
+    \l{terminal}{Terminal} example illustrates the
+    asynchronous approach.
 
     The purpose of this example is to demonstrate a pattern that you can use
     to simplify your serial programming code, without losing responsiveness
@@ -64,7 +65,7 @@
     necessarily add unmanagable complexity to your application.
 
     This application is a Slave, that demonstrate the work paired with Master
-    application \l{blockingmaster}{Blocking Master Example}.
+    application \l{Blocking Master Example}.
 
     The Slave application is receives the request via serial port from
     the Master application and send a response to it.
@@ -104,7 +105,7 @@
     serial port name, timeout and response data from the member data, and then
     releasing the lock again. The case that we are protecting ourselves against
     is that \c startSlave() could be called at the same time as we are fetching
-    this data. QString is \l reentrant but \e not \l{thread-safe}, and we must
+    this data. QString is reentrant but not thread-safe, and we must
     also avoid the unlikely risk of reading the serial port name from one startup,
     call and timeout or response data of another. And as you might have guessed,
     SlaveThread can only handle one startup at a time.
@@ -160,5 +161,5 @@
 
     \snippet blockingslave/slavethread.cpp 13
 
-    \sa {Simple Terminal Example}, {Blocking Master Example}
+    \sa {Terminal Example}, {Blocking Master Example}
 */
diff --git a/examples/serialport/doc/terminal.qdoc b/examples/serialport/doc/terminal.qdoc
index b432390b..e74e237d 100644
--- a/examples/serialport/doc/terminal.qdoc
+++ b/examples/serialport/doc/terminal.qdoc
@@ -48,16 +48,18 @@
     and performed when the control returns to Qt's event loop. QSerialPort emits
     a signal when the operation is finished. For example, QSerialPort::write()
     returns immediately. When the data is sent to the serial port, QSerialPort
-    emits \l{QSerialPort::bytesWritten()}{bytesWritten()}.
+    emits \l{QIODevice::bytesWritten()}{bytesWritten()}.
 
     \li \e{The synchronous (blocking) approach.} In non-GUI and multithreaded
     applications, the \c waitFor...() functions can be called (i.e.
-    QSerialPort::waitReadyRead()) to suspend the calling thread until the
+    QSerialPort::waitForReadyRead()) to suspend the calling thread until the
     operation has completed.
 
     \endlist
 
-    In this example, the asynchronous approach is demonstrated.
+    In this example, the asynchronous approach is demonstrated. The
+    \l{blockingslave}{Blocking Slave} example illustrates the synchronous
+    approach.
 
     Our example contains some GUI widgets:
 
@@ -72,9 +74,9 @@
     main window, displaying the transmitted or received data. The widget is
     derived from the QPlainTextEdit class.
 
-    \li \l{terminal/settingsdialog.cpp}{SettingsDialog} - is a dialog
-    for configuring the serial port, as well as for displaying the available
-    serial ports and information about them.
+    \li \l{terminal/settingsdialog.cpp}{SettingsDialog} - is a dialog for
+    configuring the serial port, as well as for displaying the available serial
+    ports and information about them.
 
     \endlist
 
@@ -87,8 +89,8 @@
     \snippet terminal/mainwindow.cpp 1
 
     The only QSerialPort signal invoked in this example is
-    QSerialPort::readyRead(), which shows that new data has been received and
-    hence available:
+    \l{QIODevice::readyRead()}{readyRead()}, which shows that new data has been
+    received and hence available:
 
     \dots
     \snippet terminal/mainwindow.cpp 2
@@ -140,5 +142,5 @@
     about the selected port, and set the desired parameters of the given serial
     port.
 
-    \sa {Blocking Simple Terminal Example}
+    \sa {Blocking Slave Example}
 */