Rename QDeclarative symbols to QQuick and QQml

Symbols beginning with QDeclarative are already exported
by the quick1 module.

Users can apply the bin/rename-qtdeclarative-symbols.sh
script to modify client code using the previous names of the
renamed symbols.

Task-number: QTBUG-23737
Change-Id: Ifaa482663767634931e8711a8e9bf6e404859e66
Reviewed-by: Martin Jones <martin.jones@nokia.com>

1 files changed, 7 insertions, 7 deletions

diff --git a/doc/src/qml/qtprogrammers.qdoc b/doc/src/qml/qtprogrammers.qdoc
index 215f71859c..9338a2c29f 100644
--- a/doc/src/qml/qtprogrammers.qdoc
+++ b/doc/src/qml/qtprogrammers.qdoc
@@ -44,7 +44,7 @@ QML provides direct access to the following concepts from Qt:
  \o QAction - the \l {QML Basic Types}{action} type
  \o QObject signals and slots - available as functions to call in JavaScript
  \o QObject properties - available as variables in JavaScript
- \o QWidget - QDeclarativeView is a QML-displaying widget
+ \o QWidget - QQuickView is a QML-displaying widget
  \o Qt models - used directly in data binding (QAbstractItemModel)
 \endlist
 
@@ -71,12 +71,12 @@ QML Items also serve these purposes. Each is considered separately below.
 
 \section2 Simple Widgets
 
-The most important rule to remember while implementing a new QDeclarativeItem in C++
+The most important rule to remember while implementing a new QQuickItem in C++
 is that it should not contain any look and feel policies; leave that to the QML
 usage of the item.
 
 As an example, imagine you wanted a reusable Button item. If you therefore decided
-to write a QDeclarativeItem subclass to implement a button, just as QToolButton
+to write a QQuickItem subclass to implement a button, just as QToolButton
 subclasses QWidget for this purpose, following the rule above, your
 \c QDeclarativeButton would not have any appearance; just the notions of enabled,
 triggering, etc.
@@ -92,7 +92,7 @@ between states, and exactly how it responds to mouse, key, or touch input, shoul
 all be left for definition in QML.
 
 It is illustrative to note that QDeclarativeTextEdit is built upon QTextControl,
-QDeclarativeWebView is built upon QWebPage, and ListView uses QAbstractItemModel,
+QQuickWebView is built upon QWebPage, and ListView uses QAbstractItemModel,
 just as QTextEdit, QWebView, and QListView are built upon those same UI-agnostic
 components.
 
@@ -167,7 +167,7 @@ QGraphicsWidgets are usually designed to be laid out with QGraphicsLayouts. QML
 not use QGraphicsLayouts, as the Qt layouts do not mix well with animated and fluid
 UIs, so the geometry interface is one of the main differences. When writing QML
 elements, you allow the designers to place their bounding rectangle using absolute
-geometry, bindings or anchors (all set up for you when you inherit QDeclarativeItem)
+geometry, bindings or anchors (all set up for you when you inherit QQuickItem)
 and you do not use layouts or size hints. If size hints are appropriate, then place
 them in the QML documentation so that the designers know how to use the item best,
 but still have complete control over the look and feel.
@@ -182,14 +182,14 @@ look and feel (which involves the UI logic) can be written in QML.
 
 Both differences are caused by the different method of interaction. QGraphicsWidget
 is a QGraphicsObject subclass which makes fluid UI development from C++ easier, and
-QDeclarativeItem is a QGraphicsObject subclass which makes fluid UI development
+QQuickItem is a QGraphicsObject subclass which makes fluid UI development
 from QML easier. The difference, therefore, is primarily one of the interface
 exposed, and the design of the items that come with it; the declarative primitives
 for QML and nothing for QGraphicsWidget, because you need to write your own UI
 logic into the subclass.
 
 If you wish to use both QML and C++ to write the UI, for example to ease the
-transition period, it is recommended to use QDeclarativeItem subclasses, although
+transition period, it is recommended to use QQuickItem subclasses, although
 you can use QGraphicsWidgets as well. To allow for easier use from C++, make the
 root item of each C++ component a \l LayoutItem, and load individual "widgets" of
 QML (possibly comprised of multiple files, and containing a self-contained bundle