summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/src/declarative/qml-intro.qdoc7
-rw-r--r--doc/src/declarative/qmlruntime.qdoc12
-rw-r--r--doc/src/examples/qml-twitter.qdoc4
-rw-r--r--doc/src/getting-started/gettingstartedqml.qdoc36
-rw-r--r--doc/src/images/symbian-draw-pixmap-sequence.pngbin0 -> 5724 bytes
-rw-r--r--doc/src/images/symbian-qt-draw-pixmap-sequence.pngbin0 -> 9141 bytes
-rw-r--r--doc/src/images/symbian-qt-rendering-stack-non-screenplay.pngbin0 -> 52802 bytes
-rw-r--r--doc/src/images/symbian-rendering-stack-non-screenplay.pngbin0 -> 44655 bytes
-rw-r--r--doc/src/platforms/platform-notes.qdoc50
-rw-r--r--doc/src/platforms/supported-platforms.qdoc42
-rw-r--r--doc/src/platforms/symbian-introduction.qdoc1
-rw-r--r--doc/src/snippets/declarative/qml-intro/basic-syntax.qml48
-rw-r--r--doc/src/snippets/declarative/qml-intro/sequential-animation3.qml2
-rw-r--r--[-rwxr-xr-x]doc/src/tutorials/modelview.qdoc575
14 files changed, 367 insertions, 410 deletions
diff --git a/doc/src/declarative/qml-intro.qdoc b/doc/src/declarative/qml-intro.qdoc
index 63d6825..9130be0 100644
--- a/doc/src/declarative/qml-intro.qdoc
+++ b/doc/src/declarative/qml-intro.qdoc
@@ -58,7 +58,12 @@ would be a property.
The basic syntax of an \l{QML Elements}{element} is
-\snippet doc/src/snippets/declarative/qml-intro/basic-syntax.qml basic syntax
+\code
+SomeElement {
+ id: myObject
+ ... some other things here ...
+}
+\endcode
Here we are defining a new object. We specify its 'type' first as SomeElement.
Then within matching braces { ... } we specify the various parts of our
diff --git a/doc/src/declarative/qmlruntime.qdoc b/doc/src/declarative/qmlruntime.qdoc
index d44e774..9a84237 100644
--- a/doc/src/declarative/qmlruntime.qdoc
+++ b/doc/src/declarative/qmlruntime.qdoc
@@ -104,20 +104,22 @@ can be constructed directly instead. In this case, \c application.qml is
loaded as a QDeclarativeComponent instance rather than placed into a view:
\code
- #include <QCoreApplication>
+ #include <QApplication>
#include <QDeclarativeEngine>
+ #include <QDeclarativeContext>
+ #include <QDeclarativeComponent>
int main(int argc, char *argv[])
{
- QCoreApplication app(argc, argv);
+ QApplication app(argc, argv);
QDeclarativeEngine engine;
- QDeclarativeContext *windowContext = new QDeclarativeContext(engine.rootContext());
+ QDeclarativeContext *objectContext = new QDeclarativeContext(engine.rootContext());
QDeclarativeComponent component(&engine, "application.qml");
- QObject *window = component.create(windowContext);
+ QObject *object = component.create(objectContext);
- // ... delete window and windowContext when necessary
+ // ... delete object and objectContext when necessary
return app.exec();
}
diff --git a/doc/src/examples/qml-twitter.qdoc b/doc/src/examples/qml-twitter.qdoc
index 8a0de00..c3182a0 100644
--- a/doc/src/examples/qml-twitter.qdoc
+++ b/doc/src/examples/qml-twitter.qdoc
@@ -29,8 +29,8 @@
\title Twitter Mobile
\example demos/declarative/twitter
- This demo shows how to write a mobile Twitter client in QML. Use it to
- tweet us(@qtbynokia) how much you like our demos!
+ This demo shows how to write a mobile Twitter search client in QML. Use it to
+ see what people think about Qt Quick!
\image qml-twitter-demo.png
*/
diff --git a/doc/src/getting-started/gettingstartedqml.qdoc b/doc/src/getting-started/gettingstartedqml.qdoc
index a19d281..405e791 100644
--- a/doc/src/getting-started/gettingstartedqml.qdoc
+++ b/doc/src/getting-started/gettingstartedqml.qdoc
@@ -404,13 +404,9 @@
\image qml-texteditor2_menubar.png
- */
+ \section1 Building a Text Editor
- /*!
- \page qml-textEditor3.html
- \title Building a Text Editor
-
- \section1 Declaring a TextArea
+ \section2 Declaring a TextArea
Our text editor is not a text editor if it didn't contain an editable text area.
QML's \l {TextEdit}{TextEdit} element allows the declaration of a multi-line
@@ -451,7 +447,7 @@
}
\endcode
- \section1 Combining Components for the Text Editor
+ \section2 Combining Components for the Text Editor
We are now ready to create the layout of our text editor using QML. The text
editor has two components, the menu bar we created and the text area. QML allows
@@ -494,12 +490,8 @@
\image qml-texteditor3_texteditor.png
- */
-
- /*!
- \page qml-textEditor4
- \title Decorating the Text Editor
- \section1 Implementing a Drawer Interface
+ \section1 Decorating the Text Editor
+ \section2 Implementing a Drawer Interface
Our text editor looks simple and we need to decorate it. Using QML, we can declare
transitions and animate our text editor. Our menu bar is occupying one-third of the
@@ -652,7 +644,7 @@
The first color starts at \c 0.0 and the last color is at \c 1.0.
- \section2 Where to Go from Here
+ \section3 Where to Go from Here
We are finished building the user interface of a very simple text editor.
Going forward, the user interface is complete, and we can implement the
@@ -661,7 +653,7 @@
\image qml-texteditor4_texteditor.png
- \section1 Extending QML using Qt C++
+ \section2 Extending QML using Qt C++
Now that we have our text editor layout, we may now implement the text editor
functionalities in C++. Using QML with C++ enables us to create our application
@@ -672,7 +664,7 @@
we shall implement the load and save functions in C++ and export it as a plugin.
This way, we only need to load the QML file directly instead of running an executable.
- \section2 Exposing C++ Classes to QML
+ \section3 Exposing C++ Classes to QML
We will be implementing file loading and saving using Qt and C++. C++ classes
and functions can be used in QML by registering them. The class also needs to be
@@ -687,7 +679,7 @@
\o A \c qmldir file telling the qmlviewer tool where to find the plugin
\endlist
- \section2 Building a Qt Plugin
+ \section3 Building a Qt Plugin
To build a plugin, we need to set the following in a Qt project file. First,
the necessary sources, headers, and Qt modules need to be added into our
@@ -721,7 +713,7 @@
parent's \c plugins directory.
- \section2 Registering a Class into QML
+ \section3 Registering a Class into QML
\code
In dialogPlugin.h:
@@ -771,7 +763,7 @@
file to generate the necessary meta-object code.
- \section2 Creating QML Properties in a C++ class
+ \section3 Creating QML Properties in a C++ class
We can create QML elements and properties using C++ and
\l {The Meta-Object System}{Qt's Meta-Object System}. We can implement
@@ -925,7 +917,7 @@
\c make to build and transfer the plugin to the \c plugins directory.
- \section2 Importing a Plugin in QML
+ \section3 Importing a Plugin in QML
The qmlviewer tool imports files that are in the same directory as the
application. We can also create a \c qmldir file containing the locations of
@@ -948,7 +940,7 @@
\c TARGET field in the project file. The compiled plugin is in the \c plugins directory.
- \section2 Integrating a File Dialog into the File Menu
+ \section3 Integrating a File Dialog into the File Menu
Our \c FileMenu needs to display the \c FileDialog element, containing a list of
the text files in a directory thus allowing the user to select the file by
@@ -1038,7 +1030,7 @@
\image qml-texteditor5_filemenu.png
- \section1 Text Editor Completion
+ \section2 Text Editor Completion
\image qml-texteditor5_newfile.png
diff --git a/doc/src/images/symbian-draw-pixmap-sequence.png b/doc/src/images/symbian-draw-pixmap-sequence.png
new file mode 100644
index 0000000..05e3739
--- /dev/null
+++ b/doc/src/images/symbian-draw-pixmap-sequence.png
Binary files differ
diff --git a/doc/src/images/symbian-qt-draw-pixmap-sequence.png b/doc/src/images/symbian-qt-draw-pixmap-sequence.png
new file mode 100644
index 0000000..f7546f4
--- /dev/null
+++ b/doc/src/images/symbian-qt-draw-pixmap-sequence.png
Binary files differ
diff --git a/doc/src/images/symbian-qt-rendering-stack-non-screenplay.png b/doc/src/images/symbian-qt-rendering-stack-non-screenplay.png
new file mode 100644
index 0000000..9e1997d
--- /dev/null
+++ b/doc/src/images/symbian-qt-rendering-stack-non-screenplay.png
Binary files differ
diff --git a/doc/src/images/symbian-rendering-stack-non-screenplay.png b/doc/src/images/symbian-rendering-stack-non-screenplay.png
new file mode 100644
index 0000000..80cb078
--- /dev/null
+++ b/doc/src/images/symbian-rendering-stack-non-screenplay.png
Binary files differ
diff --git a/doc/src/platforms/platform-notes.qdoc b/doc/src/platforms/platform-notes.qdoc
index 94b9856..6f533ae 100644
--- a/doc/src/platforms/platform-notes.qdoc
+++ b/doc/src/platforms/platform-notes.qdoc
@@ -526,6 +526,56 @@
platform in use. If available, it is loaded in preference over the MMF
plugin. If the Helix plugin fails to load, the MMF plugin, if present on
the device, will be loaded instead.
+
+ \section1 UI Performance in devices prior to Symbian^3
+
+ Qt uses the QPainter class to perform low-level painting on widgets and
+ other paint devices. QPainter provides functions to draw complex shapes,
+ aligned text and pixmaps. It can also do vector path clipping, coordinate
+ transformations and Porter-Duff composition. If the underlying graphics
+ architecture does not support all of these operations then Qt uses the
+ raster graphics system for rendering.
+
+ Most of the Symbian devices prior to Symbian^3 use a non-ScreenPlay
+ graphics architecture which does not have native support for all functions
+ provided by QPainter. In non-ScreenPlay devices Qt uses the raster
+ graphics system by default which has a performance penalty when compared
+ to native Symbian rendering.
+
+ In order to be able to perform all functions provided by QPainter, the
+ raster graphics system needs to have pixel level framebuffer access. To
+ make this possible in non-ScreenPlay devices Qt has to create an
+ additional offscreen buffer that is the target for all Qt rendering
+ operations. Qt renders the widget tree to the offscreen buffer and the
+ offscreen buffer is blitted to the framebuffer via Symbian Window Server.
+
+ The following table shows the rendering stacks of native Symbian and Qt in
+ non-ScreenPlay devices.
+
+ \table
+ \header \o Symbian
+ \o Qt
+ \row \o \image symbian-rendering-stack-non-screenplay.png
+ \o \image symbian-qt-rendering-stack-non-screenplay.png
+ \endtable
+
+ The following diagrams show a simplified sequence of drawing a pixmap in
+ a non-ScreenPlay device.
+
+ \table
+ \header \o Symbian
+ \row \o \image symbian-draw-pixmap-sequence.png
+ \endtable
+
+ \table
+ \header \o Qt
+ \row \o \image symbian-qt-draw-pixmap-sequence.png
+ \endtable
+
+ When compared to a native Symbian application, Qt does an additional blit
+ to the offscreen buffer before drawing to the framebuffer. That is the
+ performance penalty which needs to be paid to get all functionality
+ provided by QPainter in non-ScreenPlay architecture.
*/
/*!
diff --git a/doc/src/platforms/supported-platforms.qdoc b/doc/src/platforms/supported-platforms.qdoc
index bb80ae5..6e9fb3d 100644
--- a/doc/src/platforms/supported-platforms.qdoc
+++ b/doc/src/platforms/supported-platforms.qdoc
@@ -64,18 +64,22 @@
\row \o Linux (32 and 64-bit)
\o gcc 4.2
\row \o Microsoft Windows XP
- \o gcc 4.4 (MinGW) (32-bit), MSVC 2003, 2005 (32 and 64-bit)
+ \o gcc 4.4 (MinGW) (32-bit), MSVC 2005 (32 and 64-bit)
\row \o Microsoft Windows Vista
\o MSVC 2005, 2008
\row \o Microsoft Windows Vista 64bit
\o MSVC 2008
- \row \o Apple Mac OS X 10.5 "Leopard" x86_64 (Carbon, Cocoa 32 and 64bit)
+ \row \o Microsoft Windows 7
+ \o MSVC 2008
+ \row \o Apple Mac OS X 10.6 "Snow Leopard"
+ \o As provided by Apple
+ \row \o Apple Mac OS X 10.5 "Leopard" x86_64 (Cocoa 32 and 64bit)
\o As provided by Apple
\row \o Embedded Linux QWS (ARM)
\o gcc (\l{http://www.codesourcery.com/}{Codesourcery version)}
\row \o Windows CE 5.0 (ARMv4i, x86, MIPS)
\o MSVC 2005 WinCE 5.0 Standard (x86, pocket, smart, mipsii)
- \row \o Symbian (Symbian/S60 3.1, 3.2 and 5.0)
+ \row \o Symbian (Symbian/S60 5.0)
\o RVCT 2.2 [build 686 or later], WINSCW 3.2.5 [build 482 or later], GCCE (for applications)
\endtable
@@ -90,19 +94,15 @@
\table
\header \o Platform
\o Compilers
- \row \o Windows XP, Vista
- \o gcc 3.4.2 (MinGW)
\row \o Windows 7
- \o MSVC 2008
- \row \o Apple Mac OS X 10.6 "Snow Leopard"
+ \o MSVC 2010
+ \row \o Apple Mac OS X 10.4 "Tiger" (Carbon)
\o As provided by Apple
- \row \o Apple Mac OS X 10.4 "Tiger"
+ \row \o Apple Mac OS X 10.5 "Leopard" (Carbon)
\o As provided by Apple
- \row \o HPUXi 11.11
- \o aCC 3.57, gcc 3.4
\row \o HPUXi 11.23
\o aCC 6.10
- \row \o Solaris 10 (UltraSparc, x86)
+ \row \o Solaris 10 UltraSparc
\o Sun Studio 12
\row \o AIX 6
\o Power5 xlC 7
@@ -114,8 +114,14 @@
\o gcc (\l{http://www.codesourcery.com/}{Codesourcery version)}
\row \o Embedded Linux X11 (ARM)
\o gcc (\l{http://www.scratchbox.org/}{Scratchbox)}
+ \row \o Windows CE 5.0 (ARMv4i, x86, MIPS)
+ \o MSVC 2005 WinCE 5.0 Standard (x86, pocket, smart, mipsii)
\row \o Windows CE 6.0 (ARMv4i, x86, MIPS)
\o MSVC 2008 WinCE 6.0 Professional
+ \row \o Maemo 5(Linux, ARM, X11)
+ \o gcc (\l{http://www.scratchbox.org/}{Scratchbox)}
+ \row \o Symbian (Symbian/S60 3.1, 3.2)
+ \o RVCT 2.2 [build 686 or later], WINSCW 3.2.5 [build 482 or later], GCCE (for applications)
\endtable
\section1 Tier 3 Platforms (Not supported by Nokia)
@@ -142,20 +148,12 @@
implied warranties of merchantability, fitness for a particular purpose, title and
non-infringement with regard to the Licensed Software.
- \section1 Planned Changes for Qt 4.7
+ \section1 Planned Changes for Qt 4.8
The following changes to the list of supported platforms are at time of publishing
- planned for Qt 4.7:
+ planned for Qt 4.8:
\list
- \o Upgrade Windows 7 to Tier 1
- \o Upgrade Mac OS X 10.6 to Tier 1
- \o Add support for Visual Studio 2010 (Tier 2)
- \o Move support for Carbon implementation of Qt on Mac OS X from Tier 1 to Tier 2
- \o Drop support for MinGW 3.4
- \o Drop support for Visual Studio 2003
- \o Drop support for HP-UX on PA-RISC
- \o Drop support for Windows Mobile 5
- \o Drop support for OpenGL ES Common Lite 1.0
+ \o Plans not yet released
\endlist
*/
diff --git a/doc/src/platforms/symbian-introduction.qdoc b/doc/src/platforms/symbian-introduction.qdoc
index 701707e..fafe007 100644
--- a/doc/src/platforms/symbian-introduction.qdoc
+++ b/doc/src/platforms/symbian-introduction.qdoc
@@ -219,6 +219,7 @@
\row \o -o \o Creates only unsigned package.
\row \o -s \o Generates stub sis for ROM.
\row \o -n <name> \o Specifies the final sis name.
+ \row \o -g \o Treat gcce platform as armv5.
\endtable
Execute the \c{createpackage.pl} script without any
diff --git a/doc/src/snippets/declarative/qml-intro/basic-syntax.qml b/doc/src/snippets/declarative/qml-intro/basic-syntax.qml
deleted file mode 100644
index 686a927..0000000
--- a/doc/src/snippets/declarative/qml-intro/basic-syntax.qml
+++ /dev/null
@@ -1,48 +0,0 @@
-/****************************************************************************
-**
-** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
-** All rights reserved.
-** Contact: Nokia Corporation (qt-info@nokia.com)
-**
-** This file is part of the QtDeclarative module of the Qt Toolkit.
-**
-** $QT_BEGIN_LICENSE:BSD$
-** You may use this file under the terms of the BSD license as follows:
-**
-** "Redistribution and use in source and binary forms, with or without
-** modification, are permitted provided that the following conditions are
-** met:
-** * Redistributions of source code must retain the above copyright
-** notice, this list of conditions and the following disclaimer.
-** * Redistributions in binary form must reproduce the above copyright
-** notice, this list of conditions and the following disclaimer in
-** the documentation and/or other materials provided with the
-** distribution.
-** * Neither the name of Nokia Corporation and its Subsidiary(-ies) nor
-** the names of its contributors may be used to endorse or promote
-** products derived from this software without specific prior written
-** permission.
-**
-** THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-** "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-** LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-** A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-** OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-** SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-** LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-** DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-** THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-** (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-** OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE."
-** $QT_END_LICENSE$
-**
-****************************************************************************/
-
-// Note: this file is not intended to be run.
-
-//! [basic syntax]
-SomeElement {
- id: myObject
- ... some other things here ...
-}
-//! [basic syntax]
diff --git a/doc/src/snippets/declarative/qml-intro/sequential-animation3.qml b/doc/src/snippets/declarative/qml-intro/sequential-animation3.qml
index f83a966..6926f8a 100644
--- a/doc/src/snippets/declarative/qml-intro/sequential-animation3.qml
+++ b/doc/src/snippets/declarative/qml-intro/sequential-animation3.qml
@@ -39,6 +39,8 @@
****************************************************************************/
//! [document]
+import Qt 4.7
+
Rectangle {
id: mainRec
width: 600
diff --git a/doc/src/tutorials/modelview.qdoc b/doc/src/tutorials/modelview.qdoc
index b39a01c..65f6674 100755..100644
--- a/doc/src/tutorials/modelview.qdoc
+++ b/doc/src/tutorials/modelview.qdoc
@@ -29,22 +29,28 @@
\page modelview.html
\startpage {index.html}{Qt Reference Documentation}
- \nextpage {modelview-part1.html}{Introduction}
\title Model/View Contents
\brief An introduction to ModelView programming
- This tutorial gives an introduction to ModelView programming using the Qt
- cross-platform framework.
+ Every UI developer should know about ModelView programming and the goal of
+ this tutorial is to provide you with an easily understandable introduction
+ to this topic.
+
+ Table, list and tree widgets are components frequently used in GUIs. There
+ are 2 different ways how these widgets can access their data. The
+ traditional way involves widgets which include internal containers for
+ storing data. This approach is very intuitive, however, in many non-trivial
+ applications, it leads to data synchronization issues.
+ The second approach is model/view programming, in
+ which widgets do not maintain internal data containers. They access external
+ data through a standardized interface and therefore avoid data duplication.
+ This may seem complicated at first, but once you take a closer look, it is
+ not only easy to grasp, but the many benefits of model/view programming also
+ become clearer.
\image treeview.png
- \omit
- It doesn't cover everything; the emphasis is on teaching the programming
- philosophy of Model/View programming, and Qt's features are introduced as
- needed. Some commonly used features are never used in this tutorial.
- \endomit
-
In the process, we will learn about some basic technologies provided by Qt,
such as:
@@ -52,38 +58,29 @@
\o The difference between standard and model/view widgets
\o Adapters betweeen forms and models
\o Developing a simple model/view application
+ \o Predefined models
\o Intermediate topics such as:
\list
\o Tree views
\o Selection
- \o Predefined models
\o Delegates
\o Debugging with model test
\endlist
\endlist
- If you are completely new to Qt, please read \l{How to Learn Qt} if you
- have not already done so.
-
- The tutorial's source code is located in Qt's \c examples/tutorials/modelview
- directory.
+ You will also learn whether your new application can be written easier with
+ model/view programming or if classic widgets will work just as well.
- \list 1
- \o \l{modelview-part1.html}{Introduction}
- \o \l{modelview-part2.html}{Developing a Simple Model/View Application}
- \o \l{modelview-part3.html}{Intermediate Topics}
- \o \l{modelview-part4.html}{Good Sources of Additional Information}
- \endlist
+ This tutorial includes example code for you to edit and integrate into your
+ project. The tutorial's source code is located in Qt's
+ \c examples/tutorials/modelview directory.
+ For more detailed information you may also want to look at the
+ \l{model-view-programming.html}{reference documentation}
-*/
+ If you are completely new to Qt, please read \l{How to Learn Qt} if you
+ have not already done so.
-/*!
- \page modelview-part1.html
- \contentspage {modelview.html}{Model/View Contents}
- \previouspage {modelview.html}{Model/View Contents}
- \nextpage {modelview-part2.html}{Developing a Simple Model/View Application}
- \title An Introduction to Model/View Programming
\section1 1. Introduction
@@ -104,16 +101,16 @@
\section2 1.1 Standard Widgets
Let's have a closer look at a standard table widget. A table widget is a 2D
- array of the data elements that the user can change. The table widget can
- be integrated into a program flow by reading and writing the data elements
- that the table widget provides. This method is very intuitive and useful in
- many applications.
+ array of the data elements that the user can change. The table widget can be
+ integrated into a program flow by reading and writing the data elements that
+ the table widget provides. This method is very intuitive and useful in many
+ applications.
Displaying and editing a database table with a standard table widget can be
problematic. Two copies of the data have to be coordinated: one outside the
- widget; one inside the widget. The developer needs to know where up-to-date
- data is so the both copies contain the most recent data. The tight coupling
- of presentation and data makes it harder to write unit tests.
+ widget; one inside the widget. The developer is responsible for
+ synchronizing both versions. The tight coupling of presentation and data
+ makes it harder to write unit tests.
\section2 1.2 Model/View to the Rescue
@@ -121,14 +118,14 @@
architecture. Model/view eliminates the data consistency problems that may
occur with standard widgets. Model/view also makes it easier to use more
than one view of the same data because one model can be passed on to many
- views. The most important difference is that model/view widgets do not
- store data behind the table cells. In fact, they operate directly from your
- data. Since view classes do not know your data's structure, you need to
- provide a wrapper to make your data conform to the QAbstractItemModel
- interface. A view uses this interface to read from and write to your data
- and any class that implements QAbstractItemModel is a model. Once the view
- receives a pointer to a model, it will read and display its content and be
- its editor.
+ views. The most important difference is that model/view widgets do not store
+ data behind the table cells. In fact, they operate directly from your data.
+ Since view classes do not know your data's structure, you need to provide a
+ wrapper to make your data conform to the QAbstractItemModel interface. A
+ view uses this interface to read from and write to your data. Any instance
+ of a class that implements QAbstractItemModel is said to be a model. Once
+ the view receives a pointer to a model, it will read and display its content
+ and be its editor.
\section2 1.3 Overview of the Model/View Widgets
@@ -138,9 +135,10 @@
\table
\header
\o Widget
- \o Standard Widget (a convenience class with data in
- the widget)
- \o Model/View View Class (for use with external data)
+ \o Standard Widget\br
+ (an item based convenience class)
+ \o Model/View View Class\br
+ (for use with external data)
\row
\o \inlineimage listview.png
\o \l QListWidget
@@ -167,47 +165,26 @@
Having adapters between forms and models can come in handy.
- We often prefer editing data stored in tables (e.g. in database tables) in
- forms rather than in tables. There is no direct model/view counterpart for
- separating data and views for widgets that operate on one value instead of
- a dataset, so we need an adapter in order to connect the form to the source
- of data.
+ We can edit data stored in tables directly from within the table itself, but
+ it's much more comfortable to edit data in text fields. There is no direct
+ model/view counterpart that separates data and views for widgets that
+ operate on one value (QLineEdit, QCheckBox ...) instead of a dataset, so we
+ need an adapter in order to connect the form to the source of data.
\l QDataWidgetMapper is a great solution because it maps form widgets to a
- table row and it makes it very easy to build forms for database tables.
+ table row and makes it very easy to build forms for database tables.
\image widgetmapper.png
- Another example of an adapter is QCompleter. Qt has QCompleter for
- providing auto-completions in Qt widgets such as QComboBox and, as shown
- below, QLineEdit. QCompleter uses a model as its data source, so QCompleter,
- in itself, is a very handy adapter.
+ Another example of an adapter is \l QCompleter. Qt has \l QCompleter for
+ providing auto-completions in Qt widgets such as \l QComboBox and, as shown
+ below, \l QLineEdit. \l QCompleter uses a model as its data source.
\image qcompleter.png
-*/
-
-/*!
- \page modelview-part2-main-cpp.html
- \title main.cpp
- \quotefile tutorials/modelview/1_readonly/main.cpp
-*/
-/*!
- \page modelview-part2.html
- \contentspage {modelview-index.html}{Model/View Contents}
- \previouspage {modelview-part1.html}{Introduction}
- \nextpage {modelview-part3.html}{Intermediate Topics}
- \title Model/View Chapter 2 - A Simple Model/View Application
\section1 2. A Simple Model/View Application
-
- If you want to develop a model/view application, where should you start? We
- recommend starting with a simple example and extending it step-by-step.
- This makes understanding the architecture a lot easier. Trying to
- understand the model/view architecture in detail before invoking the IDE
- has proven to be less convenient for many developers. It is substantially
- easier to start with a simple model/view application that has demo data.
- Give it a try! Simply replace the data in the examples below with your own.
+ If you want to develop a model/view application, where should you start? We recommend starting with a simple example and extending it step-by-step. This makes understanding the architecture a lot easier. Trying to understand the model/view architecture in detail before invoking the IDE has proven to be less convenient for many developers. It is substantially easier to start with a simple model/view application that has demo data. Give it a try! Simply replace the data in the examples below with your own.
Below are 7 very simple and independent applications that show different
sides of model/view programming. The source code can be found inside the
@@ -216,58 +193,55 @@
\section2 2.1 A Read Only Table
We start with an application that uses a QTableView to show data. We will
- add editing capabilities later.
+ add editing capabilities later.
+ (file source: examples/tutorials/modelview/1_readonly/main.cpp)
\snippet examples/tutorials/modelview/1_readonly/main.cpp Quoting ModelView Tutorial
We have the usual \l {modelview-part2-main-cpp.html}{main()} function:
- \snippet examples/tutorials/modelview/1_readonly/modelview.h Quoting ModelView Tutorial
-
- The application is a \l QMainWindow that holds a \l QTableView.
-
- \snippet examples/tutorials/modelview/1_readonly/modelview.cpp Quoting ModelView Tutorial
-
- Here is the interesting part: We use
- \l{QTableView::setModel()}{tableView->setModel(new MyModel(this));} to
- instantiate the Model and pass its pointer to \l {QTableView}{tableView()}.
- \l{QTableView}{tableView} will invoke the methods of the pointer it has
- received to find out two things:
+ Here is the interesting part: We create an instance of MyModel and use
+ \l{QTableView::setModel()}{tableView.setModel(&myModel);} to pass a
+ pointer of it to to \l{QTableView}{tableView}. \l{QTableView}{tableView}
+ will invoke the methods of the pointer it has received to find out two
+ things:
\list
- \o How many rows and columns should be displayed
- \o What content should be printed into each cell.
+ \o How many rows and columns should be displayed.
+ \o What content should be printed into each cell.
\endlist
- The model needs some code to respond to this.
+ The model needs some code to respond to this.
We have a table data set, so let's start with QAbstractTableModel since it
- is easier to use.
+ is easier to use than the more general QAbstractItemModel.
+ (file source: examples/tutorials/modelview/1_readonly/mymodel.h)
\snippet examples/tutorials/modelview/1_readonly/mymodel.h Quoting ModelView Tutorial
QAbstractTableModel requires the implementation of three abstract methods.
+ (file source: examples/tutorials/modelview/1_readonly/mymodel.cpp)
\snippet examples/tutorials/modelview/1_readonly/mymodel.cpp Quoting ModelView Tutorial
- The number of rows and columns is set by
+ The number of rows and columns is provided by
\l{QAbstractItemModel::rowCount()}{MyModel::rowCount()} and
- \l{QAbstractItemModel::columnCount()}{MyModel::columnCount()}.
- When the view has to know what the cell's text is, it calls the method.
- Row and column information is specified with parameter \c index and the
- role is set to \l{Qt::ItemDataRole}{Qt::DisplayRole}. Other roles are
- covered in the next section. In our example, the data that should be
- displayed is generated. In a real application, \c MyModel would have a
- member called \c MyData, which serves as the target for all reading and
- writing operations.
+ \l{QAbstractItemModel::columnCount()}{MyModel::columnCount()}. When the view
+ has to know what the cell's text is, it calls the method
+ \l{QAbstractItemModel::data()}{MyModel::data()}. Row and column information
+ is specified with parameter \c index and the role is set to
+ \l{Qt::ItemDataRole}{Qt::DisplayRole}. Other roles are covered in the next
+ section. In our example, the data that should be displayed is generated. In
+ a real application, \c MyModel would have a member called \c MyData, which
+ serves as the target for all reading and writing operations.
This small example demonstrates the passive nature of a model. The model
does not know when it will be used or which data is needed. It simply
- provides data each time the view requests it.
+ provides data each time the view requests it.
- What happens when the model 's data needs to be changed? How does the view
- know when data changes and needs to be read again? The model has to emit a
- signal that indicates what range of cells has changed. This will be
+ What happens when the model's data needs to be changed? How does the view
+ realize that data has changed and needs to be read again? The model has to
+ emit a signal that indicates what range of cells has changed. This will be
demonstrated in section 2.3.
\section2 2.2 Extending the Read Only Example with Roles
@@ -276,12 +250,14 @@
controls the text's appearance. When we slightly change the model, we get
the following result: \image readonlytable_role.png
- In fact, nothing except for the \l{QAbstractItemModel::}{data()}
- method needs to be changed to set fonts, background colour, alignment and a
+ In fact, nothing except for the \l{QAbstractItemModel::}{data()} method
+ needs to be changed to set fonts, background colour, alignment and a
checkbox.
- Here is the \l{QAbstractItemModel::data()}{data()} method that produces the
- result shown above:
+ Below is the \l{QAbstractItemModel::data()}{data()} method that produces the
+ result shown above. The difference is that this time we use parameter int
+ role to return different pieces of information depending on its value.
+ (file source: examples/tutorials/modelview/2_formatting/mymodel.cpp)
\snippet examples/tutorials/modelview/2_formatting/mymodel.cpp Quoting ModelView Tutorial
Each formatting property will be requested from the model with a separate
@@ -290,42 +266,45 @@
\table
\header
- \o Role (enum Qt::ItemDataRole )
+ \o \l{Qt::ItemDataRole}{enum Qt::ItemDataRole}
\o Meaning
- \o Type
+ \o Type
\row
- \o \l{Qt::ItemDataRole}{Qt::DisplayRole}
+ \o \l{Qt::ItemDataRole}{}Qt::DisplayRole
\o text
\o QString
\row
- \o Qt::FontRole
+ \o \l{Qt::ItemDataRole}{Qt::FontRole}
\o font
\o QFont
\row
- \o Qt::BackgroundRole
+ \o \l{Qt::ItemDataRole}{BackgroundRole}
\o brush for the background of the cell
\o QBrush
\row
- \o Qt::TextAlignmentRole
+ \o \l{Qt::ItemDataRole}{Qt::TextAlignmentRole}
\o text alignment
- \o enum Qt::AlignmentFlag
+ \o \l{Qt::AlignmentFlag}{enum Qt::AlignmentFlag}
\row
- \o {1, 3} Qt::CheckStateRole
+ \o {1, 3} \l{Qt::ItemDataRole}{Qt::CheckStateRole}
\o {1, 3} suppresses checkboxes with \l{QVariant}{QVariant()},
- sets checkboxes with Qt::Checked or Qt::Unchecked
- \o {1, 3} \l{Qt::ItemDataRole}{enum Qt::ItemDataRole}
+
+ sets checkboxes with \l{Qt::CheckState}{Qt::Checked}
+
+ or \l{Qt::CheckState}{Qt::Unchecked}
+ \o {1, 3} \l{Qt::ItemDataRole}{enum Qt::ItemDataRole}
\endtable
Refer to the Qt namespace documentation to learn more about the
- Qt::ItemDataRole enum's capabilities.
+ \l{Qt::ItemDataRole}{Qt::ItemDataRole} enum's capabilities.
- Now we need to determine how using a seperated model impacts the
+ Now we need to determine how using a separated model impacts the
application's performance, so let's trace how often the view calls the
- \l{QAbstractItemModel::}{data()} method. In order to track how often
- the view calls the model, we have put a debug statement in the
- \l{QAbstractItemModel::}{data()} method, which logs onto stdio. In
- our small example, \l{QAbstractItemModel::}{data()} will be called 42
- times.
+ \l{QAbstractItemModel::}{data()} method. In order to track how often the
+ view calls the model, we have put a debug statement in the
+ \l{QAbstractItemModel::}{data()} method, which logs onto the error output
+ stream. In our small example, \l{QAbstractItemModel::}{data()} will be
+ called 42 times.
Each time you hover the cursor over the field,
\l{QAbstractItemModel::}{data()} will be called again \mdash 7 times for
each cell. That's why it is important to make sure that your data is
@@ -339,6 +318,7 @@
We still have a read only table, but this time the content changes every
second because we are showing the current time.
+ (file source: examples/tutorials/modelview/3_changingmodel/mymodel.cpp)
\snippet examples/tutorials/modelview/3_changingmodel/mymodel.cpp quoting mymodel_QVariant
Something is missing to make the clock tick. We need to tell the view every
@@ -346,17 +326,18 @@
this with a timer. In the constructor, we set its interval to 1 second and
connect its timeout signal.
+ (file source: examples/tutorials/modelview/3_changingmodel/mymodel.cpp)
\snippet examples/tutorials/modelview/3_changingmodel/mymodel.cpp quoting mymodel_a
Here is the corresponding slot:
+ (file source: examples/tutorials/modelview/3_changingmodel/mymodel.cpp)
\snippet examples/tutorials/modelview/3_changingmodel/mymodel.cpp quoting mymodel_b
We ask the view to read the data in the top left cell again by emitting the
\l{QAbstractItemModel::}{dataChanged()} signal. Note that we did not
- explicitly connect the \l{QAbstractItemModel::}{dataChanged()} signal to
- the view. This happened automatically when we called
- \l{QTableView::}{setModel()}.
+ explicitly connect the \l{QAbstractItemModel::}{dataChanged()} signal to the
+ view. This happened automatically when we called \l{QTableView::}{setModel()}.
\section2 2.4 Setting up Headers for Columns and Rows
@@ -366,60 +347,58 @@
The header content, however, is set via the model, so we reimplement the
\l{QAbstractItemModel::headerData()}{headerData()} method:
+ (file source: examples/tutorials/modelview/4_headers/mymodel.cpp)
\snippet examples/tutorials/modelview/4_headers/mymodel.cpp quoting mymodel_c
+ Note that method \l{QAbstractItemModel::headerData()}{headerData()} also has
+ a parameter role which has the same meaning as in
+ \l{QAbstractItemModel::data()}{MyModel::data()}.
\section2 2.5 The Minimal Editing Example
In this example, we are going to build an application that automatically
- populates a window title with content by repeating values entered into
- table cells.
+ populates a window title with content by repeating values entered into table
+ cells. To be able to access the window title easily we put the QTableView in
+ a QMainWindow.
- The model decides whether editing capabilities are available . We only have
+ The model decides whether editing capabilities are available. We only have
to modify the model in order for the available editing capabilities to be
enabled. This is done by reimplementing the following virtual methods:
\l{QAbstractItemModel::}{setData()} and \l{QAbstractItemModel::}{flags()}.
+ (file source: examples/tutorials/modelview/5_edit/mymodel.h)
\snippet examples/tutorials/modelview/5_edit/mymodel.h Quoting ModelView Tutorial
- We use \c QStringList m_gridData to store our data. This makes
- \c m_gridData the core of MyModel. The rest of \c MyModel acts like a
- wrapper and adapts \c m_gridData to the QAbstractItemModel interface. We
- have also introduced the \c editCompleted() signal,
- which makes it possible to transfer the modified text to the window title.
-
- \snippet examples/tutorials/modelview/5_edit/mymodel.cpp quoting mymodel_d
-
- In the constructor, we fill \c QStringList gridData with 6 items (one item
- for every field in the table):
+ We use \c the two-dimensional array QString \c m_gridData to store our data.
+ This makes \c m_gridData the core of \c MyModel. The rest of \c MyModel acts
+ like a wrapper and adapts \c m_gridData to the QAbstractItemModel
+ interface. We have also introduced the \c editCompleted() signal, which
+ makes it possible to transfer the modified text to the window title.
+ (file source: examples/tutorials/modelview/5_edit/mymodel.cpp)
\snippet examples/tutorials/modelview/5_edit/mymodel.cpp quoting mymodel_e
\l{QAbstractItemModel::setData()}{setData()} will be called each time the
user edits a cell. The \c index parameter tells us which field has been
edited and \c value provides the result of the editing process. The role
- will always be set to \c Qt::EditRole because our cells only contain text.
+ will always be set to \l Qt::EditRole because our cells only contain text.
If a checkbox were present and user permissions are set to allow the
checkbox to be selected, calls would also be made with the role set to
- \c Qt::CheckStateRole.
+ \l Qt::CheckStateRole.
+ (file source: examples/tutorials/modelview/5_edit/mymodel.cpp)
\snippet examples/tutorials/modelview/5_edit/mymodel.cpp quoting mymodel_f
Various properties of a cell can be adjusted with
- \l{QAbstractItemModel::flags()}{flags()}. Returning
- \c Qt::ItemIsEditable | \c Qt::ItemIsEnabled is enough to show an editor
- that a cell has been selected. If editing one cell modifies more data than
- the data in that particular cell, the model must emit a
- \l{QAbstractItemModel::}{dataChanged()} signal in order for the data that
- has been changed to be read.
-*/
+ \l{QAbstractItemModel::flags()}{flags()}.
+
+ Returning \l{Qt::ItemFlag}{Qt::ItemIsSelectable | Qt::ItemIsEditable | Qt::ItemIsEnabled}
+ is enough to show an editor that a cell can be selected.
+
+ If editing one cell modifies more data than the data in that particular
+ cell, the model must emit a \l{QAbstractItemModel::}{dataChanged()} signal
+ in order for the data that has been changed to be read.
-/*!
- \page modelview-part3.html
- \contentspage {modelview-index.html}{Model/View Contents}
- \previouspage {modelview-part2.html}{Developing a Simple Model/View Application}
- \nextpage {modelview-part4.html}{Good Sources of Additional Information}
- \title Model/View Chapter 3 - Intermediate Topics
\section1 3. Intermediate Topics
@@ -429,28 +408,30 @@
Simply replace QTableView with QTreeView, which results in a read/write
tree. No changes have to be made to the model. The tree won't have any
hierarchies because there aren't any hierarchies in the model itself.
- \image dummy_tree.png
+ \image dummy_tree.png
QListView, QTableView and QTreeView all use a model abstraction, which is a
merged list, table and tree. This makes it possible to use several different
types of view classes from the same model.
- \image list_table_tree.png
+ \image list_table_tree.png
This is how our example model looks so far:
- \image example_model.png
+ \image example_model.png
We want to present a real tree. We have wrapped our data in the examples
above in order to make a model. This time we use QStandardItemModel, which
is a container for hierarchical data that also implements
QAbstractItemModel. To show a tree, QStandardItemModel must be populated
- with \l{QStandardItem}{QStandardItems}, which are able to hold all the
- standard properties of items like text, fonts, checkboxes or brushes.
+ with \l{QStandardItem}s, which are able to hold all the standard properties
+ of items like text, fonts, checkboxes or brushes.
+
\image tree_2_with_algorithm.png
- \snippet examples/tutorials/modelview/6_treeview/modelview.cpp Quoting ModelView Tutorial
+ (file source: examples/tutorials/modelview/6_treeview/mainwindow.cpp)
+ \snippet examples/tutorials/modelview/6_treeview/mainwindow.cpp Quoting ModelView Tutorial
We simply instantiate a QStandardItemModel and add a couple of
\l{QStandardItem}{QStandardItems} to the constructor. We can then make a
@@ -462,42 +443,45 @@
We want to access a selected item's content in order to output it into the
window title together with the hierarchy level.
+
\image selection2.png
So let's create a couple of items:
- \snippet examples/tutorials/modelview/7_selections/modelview.cpp quoting modelview_a
+ (file source: examples/tutorials/modelview/7_selections/mainwindow.cpp)
+ \snippet examples/tutorials/modelview/7_selections/mainwindow.cpp quoting modelview_a
Views manage selections within a separate selection model, which can be
- retrieved with the \l{QAbstractItemView::}{selectionModel()}
- method. We retrieve the selection Model in order to connect a slot to its
+ retrieved with the \l{QAbstractItemView::}{selectionModel()} method. We
+ retrieve the selection Model in order to connect a slot to its
\l{QAbstractItemView::}{selectionChanged()} signal.
- \snippet examples/tutorials/modelview/7_selections/modelview.cpp quoting modelview_b
+ (file source: examples/tutorials/modelview/7_selections/mainwindow.cpp)
+ \snippet examples/tutorials/modelview/7_selections/mainwindow.cpp quoting modelview_b
- We get the model index that corresponds to the selection by calling
+ We get the model index that corresponds to the selection by calling
\l{QItemSelectionModel::currentIndex()}{treeView->selectionModel()->currentIndex()}
and we get the the field's string by using the model index. Then we just
- calculate the item's \c hierarchyLevel. Top level items do not have
- parents and the \l{QAbstractItemModel::}{parent()} method will return a
- default constructed \l{QModelIndex}{QModelIndex()}. This is why we use the
+ calculate the item's \c hierarchyLevel. Top level items do not have parents
+ and the \l{QAbstractItemModel::}{parent()} method will return a default
+ constructed \l{QModelIndex}{QModelIndex()}. This is why we use the
\l{QAbstractItemModel::}{parent()} method to iterate to the top level while
counting the steps performed during iteration.
The selection model (as shown above) can be retrieved, but it can also be
set with \l{QAbstractItemView}{QAbstractItemView::setSelectionModel}. This
is how it's possible to have 3 view classes with synchronised selections
- because only one instance of a selection model is used. The instance of a
- selection model is retrieved from the first view class with
- \l{QAbstractItemView::}{selectionModel()} and the result is assigned to the
- second and third view class with \l{QAbstractItemView::}{setSelectionModel()}.
+ because only one instance of a selection model is used. To share a selection
+ model between 3 views use \l{QAbstractItemView::}{selectionModel()} and
+ assign the result to the second and third view class with
+ \l{QAbstractItemView::}{setSelectionModel()}.
\section2 3.3 Predefined Models
- The typical way to use model/view is to wrap specific data to make it
- usable with view classes. Qt, however, also provides predefined models for
- common underlying data structures. If one of the available data structures
- is suitable for your application, a predefined model can be a good choice.
+ The typical way to use model/view is to wrap specific data to make it usable
+ with view classes. Qt, however, also provides predefined models for common
+ underlying data structures. If one of the available data structures is
+ suitable for your application, a predefined model can be a good choice.
\table
\row
@@ -531,26 +515,26 @@
and is edited as text or a checkbox. The component that provides these
presentation and editing services is called a \e delegate. We are only just
beginning to work with the delegate because the view uses a default
- delegate. But imagine that we want to have a different editor.(e.g. a
+ delegate. But imagine that we want to have a different editor (e.g., a
slider or a drop down list) Or imagine that we want to present data as
- graphics. Let's take a look at an example called
- \l{Star Delegate Example}{Star Delegate}, in which stars are used to show
- a rating:
+ graphics.
+ Let's take a look at an example called \l{Star Delegate Example}{Star
+ Delegate}, in which stars are used to show a rating:
+
\image stardelegate.png
- The view has a method that replaces the default delegate and installs a
- custom delegate. This method is called
- \l{QAbstractItemView::}{setItemDelegate()}. A new delegate can be written
- by creating a class that inherits from QStyledItemDelegate. In order to
- write a delegate that displays stars and has no input capabilities, we only
- need to overwrite 2 methods.
+ The view has a \l{QAbstractItemView::}{setItemDelegate()} method that
+ replaces the default delegate and installs a custom delegate.
+ A new delegate can be written by creating a class that inherits from
+ QStyledItemDelegate. In order to write a delegate that displays stars and
+ has no input capabilities, we only need to override 2 methods.
\code
class StarDelegate : public QStyledItemDelegate
{
Q_OBJECT
public:
- StarDelegate(QWidget *parent = 0);
+ StarDelegate(QWidget *parent = 0);
void paint(QPainter *painter, const QStyleOptionViewItem &option,
const QModelIndex &index) const;
QSize sizeHint(const QStyleOptionViewItem &option,
@@ -558,16 +542,28 @@
};
\endcode
- \l{QStyledItemDelegate::}{paint()} draws stars depending on the content
- of the underlying data. The data can be looked up with parameter
- \l{QModelIndex::data()}{index.data()}.
- \l{QAbstractItemDelegate::}{sizeHint()} specifies each star's dimensions
- so the the cell will provide enough height and width to accommodate the
- stars.
+ \l{QStyledItemDelegate::}{paint()} draws stars depending on the content of
+ the underlying data. The data can be looked up by calling
+ \l{QModelIndex::data()}{index.data()}. The delegate's
+ \l{QAbstractItemDelegate::}{sizeHint()} method is used to obtain each
+ star's dimensions, so the the cell will provide enough height and width to
+ accommodate the stars.
Writing custom delegates is the right choice if you want to show your data
- with a custom graphical representation inside the grid of the view class.
- If you want to leave the grid, you can write a custom view class.
+ with a custom graphical representation inside the grid of the view class. If
+ you want to leave the grid, you would not use a custom delegate but a custom
+ view class.
+
+ Other references to delegates in Qt Documentation:
+
+ \list
+ \o \l{Spin Box Delegate Example}
+ \o \l{QAbstractItemDelegate}{QAbstractItemDelegate Class Reference}
+ \o \l{QSqlRelationalDelegate}{QSqlRelationalDelegate Class Reference}
+ \o \l{QStyledItemDelegate}{QStyledItemDelegate Class Reference}
+ \o \l{QItemDelegate}{QItemDelegate Class Reference}
+ \endlist
+
\section2 3.5 Debugging with ModelTest
@@ -575,9 +571,9 @@
Inconsistencies in the model can cause the application to crash. Since the
model is hit by numerous calls from the view, it is hard to find out which
call has crashed the application and which operation has introduced the
- problem.
+ problem.
- Qt provides software called
+ Qt Labs provides software called
\l{http://labs.qt.nokia.com/page/Projects/Itemview/Modeltest}{ModelTest},
which checks models while your programming is running. Every time the model
is changed, ModelTest scans the model and reports errors with an assert.
@@ -586,57 +582,9 @@
Unlike view classes, ModelTest uses out of range indexes to test the model.
This means your application may crash with ModelTest even if it runs
- perfectly without it. So you also need to handle all of the indexes that
- are out of range when using ModelTest.
-
-
- \section2 3.6 Model/View NG
-
- \raw HTML
- <table style="background-color:white;border:none;font: normal 13px/1.2 Verdana;">
- <tr><td align="left" valign="top" style="background-color:white;border:none;padding:5px;">
- \endraw
-
- \raw HTML
- <!-- wrap content table p has 0 padding and the padding for p outside of the table is 5px-->
- \endraw
-
- Model/View was introduced in Qt 4.0 and is a frequently used technology.
- Feedback from developers and new development trends have shown that there
- is a need to further develop the model/view technology. Therefore a
- research project originated at Nokia is looking into ways to go beyond the
- current implementation.
-
- One limitation of model/view is that view classes are basically all fixed
- grids. It is possible, but really hard to make a list view with icons
- placed on a curve; or cells expanding on mouse over events to show
- additional information.
- In order to achieve graphically rich view experiences, Model/View NG will
- use QGraphicsView to render elements. Nodel/View NG also aims to make
- model/view programming more intuitive. One way to achieve this is to have
- separate models for lists, tables and trees. The current model abstraction
- is complex because it is capable of representing a list, a table or a tree.
-
- Model/View NG is a research project. You are welcome to checkout the source
- code, monitor progress and take part in discussions at the following
- address: \l{http://labs.qt.nokia.com/page/Projects/Itemview/ItemviewsNG}
-
- \raw HTML
- </td><td align="right" valign="top">
- \endraw
-
- \inlineimage path.png
-
- \raw HTML
- </td></tr></table>
- \endraw
-*/
+ perfectly without it. So you also need to handle all of the indexes that are
+ out of range when using ModelTest.
-/*!
- \page modelview-part4.html
- \contentspage {modelview-index.html}{Model/View Contents}
- \previouspage {modelview-part3.html}{Intermediate Topics}
- \title Model/View Chapter 4 - Good Sources of Additional Information
\section1 4. Good Sources of Additional Information
@@ -666,10 +614,10 @@
\table
\header
- \o example name
- \o view class used
- \o model used
- \o aspects touched
+ \o Example name
+ \o View class used
+ \o Model used
+ \o Aspects covered
\o
\row
\o Team Leaders
@@ -695,26 +643,26 @@
\o QTableView
\o custom model based on
QAbstractTableModel
- \o read only
+ \o Read only
\o Book 1, Chapter 10, Figure 10.10
\row
\o Cities
\o QTableView
- \o custom model based on
+ \o Custom model based on
QAbstractTableModel
- \o read / write
+ \o Read / write
\o Book 1, Chapter 10, Figure 10.12
\row
\o Boolean Parser
\o QTreeView
- \o custom model based on
+ \o Custom model based on
QAbstractItemModel
- \o read only
+ \o Read only
\o Book 1, Chapter 10, Figure 10.14
\row
\o Track Editor
\o {2, 1} QTableWidget
- \o custom delegate providing a custom editor
+ \o Custom delegate providing a custom editor
\o Book 1, Chapter 10, Figure 10.15
\row
@@ -723,47 +671,47 @@
QTableView
QTreeView
\o QDirModel
- \o demonstrates the use of multiple views
+ \o Demonstrates the use of multiple views
\o Book2, Chapter 8.2
\row
\o Address Book
\o QListView
QTableView
QTreeView
- \o custom model based on
+ \o Custom model based on
QAbstractTableModel
- \o read / write
+ \o Read / write
\o Book2, Chapter 8.4
\row
\o Address Book with sorting
\o
\o QProxyModel
- \o introducing sort and filter capabilities
+ \o Introducing sort and filter capabilities
\o Book2, Chapter 8.5
\row
\o Address Book
with checkboxes
\o
\o
- \o introducing checkboxes in model/view
+ \o Introducing checkboxes in model/view
\o Book2, Chapter 8.6
\row
\o Address Book with transposed grid
\o
- \o custom proxy Model based on QAbstractProxyModel
- \o introducing a custom model
+ \o Custom proxy Model based on QAbstractProxyModel
+ \o Introducing a custom model
\o Book2, Chapter 8.7
\row
\o Address Book with drag and drop
\o
\o
- \o introducing drag and drop support
+ \o Introducing drag and drop support
\o Book2, Chapter 8.8
\row
\o Address Book with custom editor
\o
\o
- \o introducing custom delegates
+ \o Introducing custom delegates
\o Book2, Chapter 8.9
\row
\o Views
@@ -771,51 +719,51 @@
QTableView
QTreeView
\o QStandardItemModel
- \o read only
+ \o Read only
\o Book 3, Chapter 5, figure 5-3
\row
\o Bardelegate
\o QTableView
\o
- \o custom delegate for presentation based on QAbstractItemDelegate
+ \o Custom delegate for presentation based on QAbstractItemDelegate
\o Book 3, Chapter 5, figure 5-5
\row
\o Editdelegate
\o QTableView
\o
- \o custom delegate for editing based on QAbstractItemDelegate
+ \o Custom delegate for editing based on QAbstractItemDelegate
\o Book 3, Chapter 5, figure 5-6
\row
\o Singleitemview
- \o custom view based on QAbstractItemView
+ \o Custom view based on QAbstractItemView
\o
- \o custom view
+ \o Custom view
\o Book 3,
Chapter 5,
figure 5-7
\row
\o listmodel
\o QTableView
- \o custom Model based on QAbstractTableModel
- \o read only
+ \o Custom Model based on QAbstractTableModel
+ \o Read only
\o Book 3, Chapter 5, Figure 5-8
\row
\o treemodel
\o QTreeView
- \o custom Model based on QAbstractItemModel
- \o read only
+ \o Custom Model based on QAbstractItemModel
+ \o Read only
\o Book 3, Chapter 5, Figure 5-10
\row
\o edit integers
\o QListView
- \o custom Model based on QAbstractListModel
- \o read / write
+ \o Custom Model based on QAbstractListModel
+ \o Read / write
\o Book 3, Chapter 5, Listing 5-37, Figure 5-11
\row
\o sorting
\o QTableView
\o QSortFilterProxyModel applied to QStringListModel
- \o demonstrates sorting
+ \o Demonstrates sorting
\o Book 3, Chapter 5, Figure 5-12
\endtable
@@ -823,19 +771,20 @@
\section2 4.2 Qt Documentation
Qt 4.7 comes with 17 examples and 2 Demonstrations for model/view.
- The examples can be found here: \l{Item Views Examples}
+ The examples can be found on the \l{Item Views Examples} page.
+
\table
\header
\o Example name
\o View class used
\o Model used
- \o Aspects touched
+ \o Aspects covered
\row
\o Address Book
\o QTableView
\o QAbstractTableModel
QSortFilterProxyModel
- \o usage of QSortFilterProxyModel to generate different
+ \o Usage of QSortFilterProxyModel to generate different
subsets from one data pool
\row
\o Basic Sort/Filter Model
@@ -845,41 +794,41 @@
\o
\row
\o Chart
- \o custom view
+ \o Custom view
\o QStandardItemModel
- \o designing custom views that cooperate with selection models
+ \o Designing custom views that cooperate with selection models
\row
\o Color Editor Factory
\o {2, 1} QTableWidget
- \o enhancing the standard delegate with a new custom editor to choose colours
+ \o Enhancing the standard delegate with a new custom editor to choose colours
\row
\o Combo Widget Mapper
\o QDataWidgetMapper to map QLineEdit, QTextEdit and QComboBox
\o QStandardItemModel
- \o shows how a QComboBox can serve as a view class
+ \o Shows how a QComboBox can serve as a view class
\row
\o Custom Sort/Filter Model
\o QTreeView
\o QStandardItemModel
QSortFilterProxyModel
- \o subclass QSortFilterProxyModel for advanced sorting and filtering
+ \o Subclass QSortFilterProxyModel for advanced sorting and filtering
\row
\o Dir View
\o QTreeView
\o QDirModel
- \o very small example to demonstrate how to assign a model to a view
+ \o Very small example to demonstrate how to assign a model to a view
\row
\o Editable Tree Model
\o QTreeView
- \o custom tree model
- \o comprehensive example for working with trees, demonstrates
+ \o Custom tree model
+ \o Comprehensive example for working with trees, demonstrates
editing cells and tree structure with an underlying custom
model
\row
\o Fetch More
\o QListView
- \o custom list model
- \o dynamically changing model
+ \o Custom list model
+ \o Dynamically changing model
\row
\o Frozen Column
\o QTableView
@@ -888,47 +837,47 @@
\row
\o Pixelator
\o QTableView
- \o custom table model
- \o implementation of a custom delegate
+ \o Custom table model
+ \o Implementation of a custom delegate
\row
\o Puzzle
\o QListView
- \o custom list model
- \o model/view with drag and drop
+ \o Custom list model
+ \o Model/view with drag and drop
\row
\o Simple DOM Model
\o QTreeView
- \o custom tree model
- \o read only example for a custom tree model
+ \o Custom tree model
+ \o Read only example for a custom tree model
\row
\o Simple Tree Model
\o QTreeView
- \o custom tree model
- \o read only example for a custom tree model
+ \o Custom tree model
+ \o Read only example for a custom tree model
\row
\o Simple Widget Mapper
\o QDataWidgetMapper to map QLineEdit, QTextEdit and QSpinBox
\o QStandardItemModel
- \o basic QDataWidgetMapper usage
+ \o Basic QDataWidgetMapper usage
\row
\o Spin Box Delegate
\o QTableView
\o QStandardItemModel
- \o custom delegate that uses a spin box as a cell editor
+ \o Custom delegate that uses a spin box as a cell editor
\row
\o Star Delegate
\o {2, 1} QTableWidget
- \o comprehensive custom delegate example.
+ \o Comprehensive custom delegate example.
\endtable
- \l{Qt Demonstrations}{Demonstrations} are similar to examples except
- that no walkthrough is provided for the code. Demonstrations are also
- sometimes more feature rich.
+ \l{Qt Demonstrations}{Demonstrations} are similar to examples except that no
+ walkthrough is provided for the code. Demonstrations are typically more
+ feature rich than examples.
\list
\o The \bold Interview demonstration shows the same model and
selection being shared between three different views.
- \o Demonstration \bold Spreadsheet demonstrates the use of a
+ \o The \bold Spreadsheet demonstration illustrates the use of a
table view as a spreadsheet, using custom delegates to render
each item according to the type of data it contains.
\endlist
@@ -936,3 +885,9 @@
A \l{Model/View Programming}{reference document} for model/view technology
is also available.
*/
+
+/*!
+ \page modelview-part2-main-cpp.html
+ \title main.cpp
+ \quotefile tutorials/modelview/1_readonly/main.cpp
+*/
generated by cgit v0.12 at 2024-12-27 09:22:58 (GMT)