summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorNico Vertriest <nico.vertriest@digia.com>2013-09-24 12:25:12 +0200
committerThe Qt Project <gerrit-noreply@qt-project.org>2013-11-04 12:36:42 +0100
commit303fc6d4c3a7e4a15fa9e92dc5448bb8f7982509 (patch)
treefab2a186b2d3362caef9ec7a5ea519b1a7b639f6
parent76d4cae393305a1a87e53b88ef80a2a1a87758b7 (diff)
Doc: review of QtSensors
Minor corrections in compatmap.qdoc Task-number: QTBUG-32173 Change-Id: Ic4f881449e65c2d6889f0e217d251214997a8a56 Reviewed-by: Martin Smith <martin.smith@digia.com> Reviewed-by: Laszlo Papp <lpapp@kde.org> Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
-rw-r--r--src/sensors/doc/src/compatmap.qdoc4
-rw-r--r--src/sensors/doc/src/genericbackend.qdoc2
-rw-r--r--src/sensors/doc/src/porting.qdoc19
-rw-r--r--src/sensors/doc/src/qtsensorgestures-cpp.qdoc18
-rw-r--r--src/sensors/doc/src/qtsensorgestures-emulator.qdoc16
-rw-r--r--src/sensors/doc/src/qtsensorgestures-plugins.qdoc42
-rw-r--r--src/sensors/doc/src/qtsensors-backend.qdoc104
-rw-r--r--src/sensors/doc/src/qtsensors-cpp.qdoc24
-rw-r--r--src/sensors/doc/src/qtsensors.qdoc9
-rw-r--r--src/sensors/doc/src/qtsensors5.qdoc8
-rw-r--r--src/sensors/doc/src/sensorfwbackend.qdoc8
11 files changed, 133 insertions, 121 deletions
diff --git a/src/sensors/doc/src/compatmap.qdoc b/src/sensors/doc/src/compatmap.qdoc
index e3a35304..a287a827 100644
--- a/src/sensors/doc/src/compatmap.qdoc
+++ b/src/sensors/doc/src/compatmap.qdoc
@@ -219,11 +219,11 @@
1) Support depends on the underlying platform
- In addition to the table above, each sensor type might support specific features. For example
+ In addition to the table above, each sensor type might support specific features. For example,
a magnetometer might support returning geo values. See QSensor::isFeatureSupported() for
additional details.
- Sensor Gestures are mostly platform independent, and will run if the platform has the needed sensors.
+ Sensor Gestures are mostly platform independent, and will run if the platform has the sensors required.
Whether they are supported and work well or not depends on the platform.
*/
diff --git a/src/sensors/doc/src/genericbackend.qdoc b/src/sensors/doc/src/genericbackend.qdoc
index a273352b..aa0e5a77 100644
--- a/src/sensors/doc/src/genericbackend.qdoc
+++ b/src/sensors/doc/src/genericbackend.qdoc
@@ -53,6 +53,6 @@
\li Tilt Sensor
\li Accelerometer
\endtable
- If a platform doesn't support the source sensor, then the sensor can not be emulated.
+ If a platform doesn't support the source sensor, then the sensor cannot be emulated.
*/
diff --git a/src/sensors/doc/src/porting.qdoc b/src/sensors/doc/src/porting.qdoc
index 0d5b5723..a96231d8 100644
--- a/src/sensors/doc/src/porting.qdoc
+++ b/src/sensors/doc/src/porting.qdoc
@@ -28,6 +28,8 @@
/*!
\page qtsensors-porting.html
\title Porting Applications from QtMobility Sensors to Qt Sensors
+ \brief Explain how to port from QtMobility Sensors to Qt Sensors
+ \since Qt 5.1
\tableofcontents
@@ -35,22 +37,22 @@
The initial release of Qt Sensors (5.0) is generally expected to be source
compatible with QtMobility Sensors 1.2. This document attempts to explain
- where things must be changed in order to port applications to Qt Sensors.
+ where things need to be changed in order to port applications to Qt Sensors.
\section1 QML
- In QtMobility, the C++ classes like QAccelerometer were directly used as QML types.
+ In \c QtMobility, the C++ classes like \c QAccelerometer were directly used as QML types.
In Qt Sensors, there are now separate classes for the QML types, which have no public
C++ API.
The new QML types in Qt Sensors fix some issues the former QtMobility QML types had,
for example:
\list
- \li The reading types now have proper change notifications
- \li \c availableDataRates and \c outputRanges of the \c Sensor type are now proper list types
- \li The \c identifier and \c type properties of \c Sensor can now be used
- \li The \c lux property of \c LightSensorReading has been renamed to \c illuminance
- \li The \c QmlSensors singleton now allows to query for sensor types
+ \li The reading types now have proper change notifications.
+ \li \c availableDataRates and \c outputRanges of the \c Sensor type are now proper list types.
+ \li The \c identifier and \c type properties of \c Sensor can now be used.
+ \li The \c lux property of \c LightSensorReading has been renamed to \c illuminance.
+ \li The \c QmlSensors singleton now allows to query for sensor types.
\endlist
For more information, see the \l {Qt Sensors QML Types}{QML API} documentation.
@@ -114,7 +116,8 @@
MOBILITY += sensors
\endcode
- Applications should remove these lines and instead use this to enable the Qt Sensors API.
+ Applications should remove these lines and instead use the following statement to enable
+ the Qt Sensors API:
\code
QT += sensors
diff --git a/src/sensors/doc/src/qtsensorgestures-cpp.qdoc b/src/sensors/doc/src/qtsensorgestures-cpp.qdoc
index 70aa3e61..3ffbb5a7 100644
--- a/src/sensors/doc/src/qtsensorgestures-cpp.qdoc
+++ b/src/sensors/doc/src/qtsensorgestures-cpp.qdoc
@@ -28,22 +28,24 @@
/*!
\page qtsensorgestures-cpp.html
\title Sensor Gestures C++ Overview
-\brief Information about the QtSensorGestures C++ API
+\brief Explains how to use the QtSensorGestures C++ API
\tableofcontents
\section1 Using QtSensorGestures
With the Sensor Gestures classes, you are able to easily utilize device gesturing using
-sensors such as the accelerometer and proximity.
+sensors, such as the accelerometer and proximity.
A list of currently supported sensor gestures and their descriptions can be found here:
\l {Qt Sensor Gestures}
-Using QtSensorGestures is easy. There are two main classes you will need to use.
+Using \c QtSensorGestures is easy. There are two main classes you will need to use:
-QSensorGestureManager can be used for determining what sensor gestures are available, and
-QSensorGesture for connecting the sensor gesture signals.
+\list
+ \li QSensorGestureManager: can be used for determining which sensor gestures are available.
+ \li QSensorGesture : for connecting the sensor gesture signals.
+\endlist
\snippet sensorgestures/creating.cpp Receiving sensor gesture signals
@@ -52,15 +54,15 @@ More information about the sensor gesture recognizers can be found in
\section1 Main Classes
-The primary classes that make up the QtSensorGestures API.
+The primary classes that make up the QtSensorGestures API:
\annotatedlist sensorgestures_main
-The primary classes that make up the QtSensorGesturesRecognizers API.
+The primary classes that make up the \c QtSensorGesturesRecognizers API:
\annotatedlist sensorgestures_recognizer
-Details of the QSensorGesturePlugins available
+Details of the \c QSensorGesturePlugins available
\annotatedlist sensorgesture_plugins_topics
diff --git a/src/sensors/doc/src/qtsensorgestures-emulator.qdoc b/src/sensors/doc/src/qtsensorgestures-emulator.qdoc
index af061e2a..ca10035f 100644
--- a/src/sensors/doc/src/qtsensorgestures-emulator.qdoc
+++ b/src/sensors/doc/src/qtsensorgestures-emulator.qdoc
@@ -27,25 +27,23 @@
/*!
\group sensorgesture_emulator_topics
\title QtSensorGestures Emulator
-\brief Information about the development of clients and recognizer plugins
- using QtSensorGestures
+\brief Explains how to develop clients and recognizer plugins using QtSensorGestures
\section1 Overview
-Whether creating client apps using Qt's built-in sensor gestures, or
-creating customized recognizers, the Emulator can be used to help develop client
-apps and recognizers.
+The Emulator can be used for both creating client apps using Qt's built-in sensor gestures,
+and for creating customized recognizers.
\section1 Developing sensor gesture clients.
For instance, the Emulator can be used for writing a client app that needs
-to use the 'slam' gesture.
+to use the "slam" gesture.
-Under the 'Sensors' heading in the Emulator control, you will see an edit
-box for 'Sensor gestures' that will contain a list of signals available
+Under the "Sensors" heading in the Emulator control, you will see an edit
+box for "Sensor gestures" that will contain a list of signals available
when your client instantiates a QSensorGesture.
-Select 'slam', and then click the 'Send' button
+Select "slam", and then click the "Send" button
to send a detected("slam") signal to the client.
*/
diff --git a/src/sensors/doc/src/qtsensorgestures-plugins.qdoc b/src/sensors/doc/src/qtsensorgestures-plugins.qdoc
index 67734aad..ffea1776 100644
--- a/src/sensors/doc/src/qtsensorgestures-plugins.qdoc
+++ b/src/sensors/doc/src/qtsensorgestures-plugins.qdoc
@@ -28,7 +28,7 @@
/*!
\group sensorgesture_plugins_topics
\title QtSensorGestures Plugins
-\brief Information about the QtSensorGestures recognizer plugins.
+\brief Explains how to develop recognizer plugins with QtSensorGestures
The QtSensorGestures recognizer plugins are the way to create your own
sensor gestures.
@@ -36,7 +36,7 @@ sensor gestures.
Creating software to recognize motion gestures using sensors is a huge subject not covered here.
The QSensorGesture API does not limit usage to any of the common classification methods of gesture
-recognition such as Hidden Markov Models, Neural Networks, Dynamic Time Warping, or even the
+recognition, such as Hidden Markov Models, Neural Networks, Dynamic Time Warping, or even the
ad-hoc heuristic recognizers of Qt's built-in sensor gesture recognizers. It's basically a
signaling system for lower level gesture recogition methods and algorithms to communicate to the
higher level applications.
@@ -45,7 +45,7 @@ higher level applications.
\section1 Overview
- The steps to creating a sensor gesture plugin are as follows:
+ The steps for creating a sensor gesture plugin are as follows:
\list
\li Sub-class from QSensorGesturePluginInterface
\li Sub-class from QSensorGestureRecognizer and implement gesture recognizer logic using QtSensors.
@@ -70,34 +70,34 @@ classes to subclass.
\target Qt Sensor Gestures
\section3 Recognizer Plugins
-The Sensor Gesture Recognizers that come with Qt are made using an ad-hock heurustic approach.
+The Sensor Gesture Recognizers that come with Qt are made using an ad-hoc heuristic approach.
The user cannot define their own gestures, and must learn how to perform and accomodate the
pre-defined gestures herein.
-A developer may use any method including computationally and training intensive well
- known classifiers, to produce gesture recognizers. There are currently no classes in Qt for
-gesture training, nor ability for the user to define their own sensor based motion gestures.
+A developer may use any method, including computationally- and training-intensive well-
+known classifiers, to produce gesture recognizers. There are currently no classes in Qt for
+gesture training, nor is it possible for the user to define his own sensor-based motion gestures.
-A procedure for writing ad-hock recognizers might include:
+A procedure for writing ad-hoc recognizers might include:
\list
- \li Obtain and gather output from the accelerometer through QAccelerometerReading of a gesture being performed.
+ \li Obtain and gather output from the accelerometer through \c QAccelerometerReading of a gesture being performed.
\li Use various methods and constraints on the accelerometer data to recognize the various states:
\list i
- \li Initial 'listening' state for a gesture
- \li Start of a possible gesture, moving into a 'detecting' state
- \li End of a possible gesture, moving into a 'recognizing' state
- \li and finally, if it is recognized, the 'recognized' state, or if not recognized, move back to
- the 'listening' state.
+ \li Initial "listening" state for a gesture
+ \li Start of a possible gesture, moving into a "detecting" state
+ \li End of a possible gesture, moving into a "recognizing" state
+ \li and finally, if it is recognized, the "recognized" state, or if not recognized, move back to
+ the "listening" state.
\endlist
\li Test procedure to make sure it is easy to perform, and will not
- produce too many false positive recognitions. And if used with other gestures, collisions. Meaning
+ produce too many false positive recognitions, or collisions if used with other gestures. Meaning
that gestures performed get recognized as another gesture instead.
\endlist
-Here is a list of included plugins and their signals
+Below you will find a list of included plugins and their signals.
-For ShakeGestures plugin:
+For the ShakeGestures plugin:
\table
\row
\li Recognizer Id
@@ -107,7 +107,7 @@ For ShakeGestures plugin:
\li shake
\endtable
-For QtSensorGestures plugin:
+For the QtSensorGestures plugin:
\table
\row
\li Recognizer Id
@@ -133,7 +133,7 @@ For QtSensorGestures plugin:
\row
\li QtSensors.pickup
\li pickup
- \li Phone is resting face up on a flat curface, and is then picked up and brought up into viewing position, using the Accelerometer sensor.
+ \li Phone is resting face up on a flat curface, and is then picked up and brought up into viewing position. Uses the Accelerometer sensor.
\li \image sensorgesture-faceup.png
\row
\li QtSensors.shake2
@@ -144,7 +144,7 @@ For QtSensorGestures plugin:
\li QtSensors.slam
\li slam
\li Phone is held in a top up position with a side facing forward for a moment. Swing it quickly with a downward motion
- like it is being used to point at something with the top corner. using the Accelerometer and Orientation sensors.
+ like it is being used to point at something with the top corner. Uses the Accelerometer and Orientation sensors.
\li \image sensorgesture-slam_1.png
\image sensorgesture-slam_2.png
\row
@@ -160,7 +160,7 @@ For QtSensorGestures plugin:
\row
\li QtSensors.whip
\li whip
- \li Move phone quickly down and then back up. using the Accelerometer and Orientation sensors.
+ \li Move phone quickly down and then back up. Uses the Accelerometer and Orientation sensors.
\li \image sensorgesture-whip.png
\endtable
diff --git a/src/sensors/doc/src/qtsensors-backend.qdoc b/src/sensors/doc/src/qtsensors-backend.qdoc
index da384c38..a64b2d1f 100644
--- a/src/sensors/doc/src/qtsensors-backend.qdoc
+++ b/src/sensors/doc/src/qtsensors-backend.qdoc
@@ -28,9 +28,10 @@
/*!
\group sensors_backend_topics
\title Qt Sensors Backend
-\brief Information about the Qt Sensors back end
+\brief Describes how to use the Qt Sensors backend.
-The Qt Sensors backend connects the Qt Sensors API to the platform services or hardware sensors.
+The Qt Sensors backend connects the Qt Sensors API to the platform services or
+hardware sensors.
\tableofcontents
@@ -39,12 +40,11 @@ The Qt Sensors backend connects the Qt Sensors API to the platform services or h
\section1 Backend API
QSensor instances talk to a backend object. Backends are usually supplied
-with the Qt Sensors library for a specific device although third party
-backends may be used as well. A backend may talk
-directly to hardware or it may talk to a system service. In some instances
-it may even talk to another sensor.
-An example of this is the orientation sensor backend that talks to an
-accelerometer to determine the device orientation.
+with the Qt Sensors library for a specific device, although third-party
+backends may be used as well. A backend can talk directly to hardware, or
+it can talk to a system service. In some instances it can even talk to
+another sensor. An example of this is the orientation sensor backend that talks
+to an accelerometer to determine the device orientation.
\section1 Backend Classes
If you are making sensors available through the Sensors API, these are the
@@ -96,42 +96,45 @@ a game these two devices are conceptually the same type.
\section1 Default sensor for a type
-To avoid the need to know (or check) what the default sensor for a type is, the system will
-use the default sensor for a type. Most of the time this is what the app developer wants to
-do. In cases where the app developer wants to select a specific sensor they must call the
-QSensor::setIdentifier() method before they start the sensor so that the appropriate backend
-is used.
+To avoid the need to know (or check) what the default sensor for a type is, the
+system will use the default sensor for a type. Most of the time this is what the
+app developer wants to do. If the app developer wants to select a specific sensor,
+he needs to call the QSensor::setIdentifier() method before starting the sensor
+so that the appropriate backend is used.
-From a system perspective though, selecting which sensor should be the default gets tricky.
-The sensors library uses the first registered identifier as the default. This means that the
-order in which sensor backends are registered is important so the system will allow a config
-file to determine the default instead.
+From a system perspective though, selecting which sensor should be the default
+gets tricky. The sensors library uses the first registered identifier as the
+default. This means that the order in which the sensor backends are registered,
+is important so the system will allow a config file to determine the default
+instead.
\section1 Sensors.conf
-The config file that determines the default sensor for a type is called Sensors.conf. If present,
-it is located in /etc/xdg/QtProject. It has the standard formatting of an ini file.
+The config file that determines the default sensor for a type is called Sensors.conf.
+If present, it is located in /etc/xdg/QtProject. It has the standard formatting
+of an ini file.
The settings live in the Default group and the general format is:
\code
type = identifier
\endcode
-An example Sensors.conf that ensures the N900 accelerometer is used as the default no matter the
-order in which backends were registered is presented here.
+An example: Sensors.conf ensures that the N900 accelerometer is used by default,
+not considering the order in which backends were registered.
\code
[Default]
QAccelerometer = n900.accelerometer
\endcode
-If Sensors.conf specifies an identifier that is not registered then the system will fall back to
-the first registered identifier as the default.
+If Sensors.conf specifies an identifier that is not registered, the system will
+fall back to the first registered identifier as the default.
-Note that there is special case logic to prevent the generic plugin's backends from becoming the
-default when another backend is registered for the same type. This logic means that a backend
-identifier starting with \c{generic.} will only be the default if no other backends have been
-registered for that type or if it is specified in \c{Sensors.conf}.
+Note that there is a special case logic to prevent the generic plugin's backends
+from becoming the default when another backend is registered for the same type.
+This logic means that a backend identifier starting with \c{generic.} will only
+be the default if no other backends have been registered for that type, or if
+it is specified in \c{Sensors.conf}.
*/
@@ -142,43 +145,46 @@ registered for that type or if it is specified in \c{Sensors.conf}.
\section1 Static Backend Registration
-Sensor backends are generally registered statically. The registration happens when the sensors
-library is first used and the registration remains in effect while the program runs.
+Sensor backends are generally registered statically. The registration happens
+when the sensors library is first used and the registration remains in effect
+while the program runs.
\image sensors-static.png
Statically registered backends may still exhibit some dynamic behaviour as the
-QSensorBackendFactory is free to return 0 to indicate that a backend cannot be created.
+QSensorBackendFactory is free to return 0 to indicate that a backend cannot be
+created.
\section1 Dynamic Backend Registration
-While static registration is fine for most backends there are some situations where this is
-problematic.
+Although static registration is fine for most backends, there are some situations
+where this is problematic.
-The clearest example is backends that represent non-fixed hardware. As an example, lets consider
-a game controller that is connected via Bluetooth. As there may be more than one game controller
-in range of the phone, the program wants to record that a specific game controller should be used.
-If the backend had been registered statically there would have been no unique information about
-the controller. Instead, the registration is delayed until the controller is seen.
+The clearest example is backends that represent non-fixed hardware. For example,
+a game controller that is connected via Bluetooth. As there may be more than one
+game controller in range of the phone, the program wants to record that a specific
+game controller should be used. If the backend had been registered statically
+there would have been no unique information about the controller. Instead, the
+registration is delayed until the controller is seen.
\image sensors-dynamic.png
\section1 Suggested Registration Policy
-A backend for fixed hardware should be registered immediately. Applications can see that the
-sensor can be used.
+A backend for fixed hardware should be registered immediately. Applications can
+see that the sensor can be used.
-A backend for remote hardware should not be registered immediately. Applications can see that
-the sensor cannot be used. When the remote hardware becomes available the backend should be
-registered. Applications can see that the sensor is now available.
+A backend for remote hardware should not be registered immediately. Applications
+can see that the sensor cannot be used. When the remote hardware becomes available,
+the backend should be registered. Applications can see that the sensor is available now.
-If it is necessary to return 0 from a factory for a backend that was registered, the backend
-should be unregistered. Applications can see that the sensor is no longer available. If the
-factory can create the backend again it should be registered. Applications can see that the
-sensor is available again.
+If it is necessary to return 0 from a factory for a backend that was registered,
+the backend should be unregistered. Applications can see that the sensor is no
+longer available. If the factory can create the backend again, it should be re-
+gistered. Applications can see that the sensor is available again.
-When the underlying hardware is no longer available, the backend should be deregistered.
-Existing instances of the backend should report error states to the application but should
-handle the situation gracefully.
+When the underlying hardware is no longer available, the backend should be
+unregistered. Existing instances of the backend should report error states to
+the application but should handle the situation gracefully.
*/
diff --git a/src/sensors/doc/src/qtsensors-cpp.qdoc b/src/sensors/doc/src/qtsensors-cpp.qdoc
index 5157ddad..583469ec 100644
--- a/src/sensors/doc/src/qtsensors-cpp.qdoc
+++ b/src/sensors/doc/src/qtsensors-cpp.qdoc
@@ -28,22 +28,22 @@
/*!
\page qtsensors-cpp.html
\title Qt Sensors C++ Overview
-\brief Information about the Qt Sensors C++ API
+\brief Explains how to use the Qt Sensors C++ API.
\tableofcontents
\section1 Sensor Types
-On a device there can be many types of sensors. Not all of the types that the Qt Sensors API
-supports may be available. There may also be types available that are not defined in the
-Qt Sensors API. The types of sensors available on a device is found using the
-\l QSensor::sensorTypes() function.
+On a device there can be many types of sensors. Not all of the types that the Qt
+Sensors API supports may be available. There may also be types available that
+are not defined in the Qt Sensors API. The types of sensors available on a device
+is found using the \l QSensor::sensorTypes() function.
For a list of built-in sensor types, see the \l{Sensor Classes} section below.
\section1 Common Conventions
-Unless otherwise specified, Qt Sensors uses the
+Unless specified otherwise, Qt Sensors uses the
\l{http://en.wikipedia.org/wiki/Cartesian_coordinate_system}{Right Hand Cartesian coordinate system}.
\image sensors-coordinates.jpg
@@ -56,12 +56,12 @@ Where rotation around an axis is used, the rotation shall be expressed as a Righ
\image sensors-coordinates3.jpg
-In general, sensor data is oriented relative to \l QPlatformScreen::nativeOrientation, i.e
-to the top of the device when the device is held in its natural orientation (normally
-when the device logo appears the right side up). If values are to be displayed on
-the screen the values may need to be transformed so that they match the user interface orientation. A sensor
-may define its data as being oriented to the UI. This will be noted in the documentation for the
-sensor.
+In general, sensor data is oriented relative to \l QPlatformScreen::nativeOrientation,
+that is to the top of the device when the device is held in its natural orientation
+(normally when the device logo appears the right side up). If values are to be
+displayed on the screen, the values may need to be transformed so that they match
+the user interface orientation. A sensor may define its data as being oriented
+to the UI. This will be noted in the documentation for the sensor.
\image sensors-sides2.jpg
diff --git a/src/sensors/doc/src/qtsensors.qdoc b/src/sensors/doc/src/qtsensors.qdoc
index 1b818c8b..002ecfed 100644
--- a/src/sensors/doc/src/qtsensors.qdoc
+++ b/src/sensors/doc/src/qtsensors.qdoc
@@ -28,10 +28,11 @@
/*!
\page qtsensors-index.html
\title Qt Sensors
- \brief The Qt Sensors API provides access to sensors via QML and C++ interfaces.
+ \brief Provides access to sensors via QML and C++ interfaces.
+ \since 5.1
The Qt Sensors API provides access to sensor hardware via QML and C++ interfaces.
- The Qt Sensors API also provides motion gesture recognition API for devices.
+ The Qt Sensors API also provides a motion gesture recognition API for devices.
\section1 Information for Application Writers
@@ -49,10 +50,10 @@
\li High-level information on how to use the C++ API.
\row
\li \l {Sensor Gestures C++ Overview}
- \li High-level information specific to sensor gestures.
+ \li High-level information specific to sensor gestures
\row
\li \l {Qt Sensors Examples}{Examples}
- \li Examples demonstrating use of the Qt Sensors APIs
+ \li Examples demonstrating the use of the Qt Sensors APIs
\endtable
\section1 Information for Backend Implementors
diff --git a/src/sensors/doc/src/qtsensors5.qdoc b/src/sensors/doc/src/qtsensors5.qdoc
index 19ee4fb3..a90694c0 100644
--- a/src/sensors/doc/src/qtsensors5.qdoc
+++ b/src/sensors/doc/src/qtsensors5.qdoc
@@ -32,9 +32,9 @@
\ingroup modules
\qtvariable sensors
- \brief The QtSensors module provides classes for reading sensor data.
+ \brief Provides classes for reading sensor data.
- Mobile devices contains sensor hardware that allow detecting changes in various physical
+ Mobile devices contain sensor hardware that allow detecting changes in various physical
properties of the device itself or its immediate environment. Examples of device properties
include the angle at which the device is held, whereas environmental properties include for
example the current level of ambient light.
@@ -45,7 +45,7 @@
\title Qt Sensors QML Types
\ingroup qmlmodules
- \brief The QtSensors QML module provides types for reading sensor data.
+ \brief Provides types for reading sensor data.
\section1 QML Module API
@@ -72,7 +72,7 @@
\section1 QML Reading types
- The data from a sensor comes through a reading class.
+ The data from a sensor comes via a reading class.
\annotatedlist qml-sensors_reading
*/
diff --git a/src/sensors/doc/src/sensorfwbackend.qdoc b/src/sensors/doc/src/sensorfwbackend.qdoc
index fcfbb5d8..160bc67e 100644
--- a/src/sensors/doc/src/sensorfwbackend.qdoc
+++ b/src/sensors/doc/src/sensorfwbackend.qdoc
@@ -30,10 +30,12 @@
\title Sensorfw Backend
\brief Information about the Sensorfw sensor backend
- The Sensorfw sensor backend requires the Sensorfw and sensor daemon. Sensorfw was originally used in MeeGo, and is available
- from http://meego.gitorious.org/meego-middleware/sensorfw
+ The Sensorfw sensor backend requires the Sensorfw and sensor daemon. Sensorfw
+ was originally used in MeeGo, and is available on :
+ http://meego.gitorious.org/meego-middleware/sensorfw
- To compile the sensorfw backend, you need sensorfw installed and run qmake with CONFIG+=sensorfw
+ To compile the sensorfw backend, you need sensorfw installed and run qmake
+ with CONFIG+=sensorfw
*/