diff options
Diffstat (limited to 'doc/src/qml/qtprogrammers.qdoc')
| -rw-r--r-- | doc/src/qml/qtprogrammers.qdoc | 14 |
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 |