doc: Correct mostly linking errors

This update corrects many qdoc warnings, mostly of the "Can't link to..."
variety, but there were also a few qdoc comments added. As of this update,
the qdoc warning count is 46 in QtDeclarative.

Change-Id: Icf2d34c7ce7010ebfd9b474feacfe8af42f3fd5f
Reviewed-by: Martin Smith <martin.smith@qt.io>

1 files changed, 21 insertions, 18 deletions

diff --git a/src/quick/handlers/qquickpointhandler.cpp b/src/quick/handlers/qquickpointhandler.cpp
index ed03685252..7e2d40452c 100644
--- a/src/quick/handlers/qquickpointhandler.cpp
+++ b/src/quick/handlers/qquickpointhandler.cpp
@@ -54,19 +54,22 @@ QT_BEGIN_NAMESPACE
     PointHandler can be used to show feedback about a touchpoint or the mouse
     position, or to otherwise react to pointer events.
 
-    When a press event occurs, each instance of PointHandler chooses a single
-    point which is not yet "taken" at that moment: if the press occurs within
-    the bounds of the \l parent, and no sibling PointHandler within the same
-    \l parent has yet acquired a passive grab on that point, and if the other
-    constraints such as \l acceptedMouseButtons, \l acceptedDevices etc. are
-    satisfied, it's eligible, and the PointHandler then acquires a passive
-    grab. In this way, the \l parent acts like an exclusive group: there can be
-    multiple instances of PointHandler, and the set of pressed touchpoints will
-    be distributed among them. Each PointHandler which has chosen a point to
-    track has its \l active property \c true. It then continues to track its
-    chosen point until release: the properties of the \l point will be kept
-    up-to-date. Any Item can bind to these properties, and thereby follow the
-    point's movements.
+    When a press event occurs, each instance of PointHandler chooses a
+    single point which is not yet "taken" at that moment: if the press
+    occurs within the bounds of the \l {PointerHandler::parent}, and
+    no sibling PointHandler within the same \l {PointerHandler::parent}
+    has yet acquired a passive grab on that point, and if the other
+    constraints such as \l {SinglePointHandler::acceptedButtons},
+    \l {PointerDeviceHandler::acceptedDevices} etc. are satisfied, it's
+    eligible, and the PointHandler then acquires a passive grab. In
+    this way, the \l {PointerHandler::parent} acts like an exclusive
+    group: there can be multiple instances of PointHandler, and the
+    set of pressed touchpoints will be distributed among them. Each
+    PointHandler which has chosen a point to track has its \l active
+    property \c true. It then continues to track its chosen point
+    until release: the properties of the \l point will be kept
+    up-to-date. Any Item can bind to these properties, and thereby
+    follow the point's movements.
 
     By being only a passive grabber, it has the ability to keep independent
     oversight of all movements. The passive grab cannot be stolen or overridden
@@ -81,11 +84,11 @@ QT_BEGIN_NAMESPACE
     types, and thus sets itself up as a potential event delivery bottleneck.
 
     One possible use case is to add this handler to a transparent Item which is
-    on top of the rest of the scene (by having a high \l z value), so that when
-    a point is freshly pressed, it will be delivered to that Item and its
-    handlers first, providing the opportunity to take the passive grab as early
-    as possible. Such an item (like a pane of glass over the whole UI) can be a
-    convenient parent for other Items which visualize the kind of reactive
+    on top of the rest of the scene (by having a high \l{Item::z} {z} value),
+    so that when a point is freshly pressed, it will be delivered to that Item
+    and its handlers first, providing the opportunity to take the passive grab
+    as early as possible. Such an item (like a pane of glass over the whole UI)
+    can be a convenient parent for other Items which visualize the kind of reactive
     feedback which must always be on top; and likewise it can be the parent for
     popups, popovers, dialogs and so on. If it will be used in that way, it can
     be helpful for your main.cpp to use QQmlContext::setContextProperty() to