source: trunk/doc/src/qt4-interview.qdoc@ 109

Last change on this file since 109 was 2, checked in by Dmitry A. Kuminov, 16 years ago

Initially imported qt-all-opensource-src-4.5.1 from Trolltech.

File size: 12.5 KB
Line 
1/****************************************************************************
2**
3** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
4** Contact: Qt Software Information ([email protected])
5**
6** This file is part of the documentation of the Qt Toolkit.
7**
8** $QT_BEGIN_LICENSE:LGPL$
9** Commercial Usage
10** Licensees holding valid Qt Commercial licenses may use this file in
11** accordance with the Qt Commercial License Agreement provided with the
12** Software or, alternatively, in accordance with the terms contained in
13** a written agreement between you and Nokia.
14**
15** GNU Lesser General Public License Usage
16** Alternatively, this file may be used under the terms of the GNU Lesser
17** General Public License version 2.1 as published by the Free Software
18** Foundation and appearing in the file LICENSE.LGPL included in the
19** packaging of this file. Please review the following information to
20** ensure the GNU Lesser General Public License version 2.1 requirements
21** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
22**
23** In addition, as a special exception, Nokia gives you certain
24** additional rights. These rights are described in the Nokia Qt LGPL
25** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
26** package.
27**
28** GNU General Public License Usage
29** Alternatively, this file may be used under the terms of the GNU
30** General Public License version 3.0 as published by the Free Software
31** Foundation and appearing in the file LICENSE.GPL included in the
32** packaging of this file. Please review the following information to
33** ensure the GNU General Public License version 3.0 requirements will be
34** met: http://www.gnu.org/copyleft/gpl.html.
35**
36** If you are unsure which license is appropriate for your use, please
37** contact the sales department at [email protected].
38** $QT_END_LICENSE$
39**
40****************************************************************************/
41
42/*!
43 \page qt4-interview.html
44 \title The Interview Framework
45
46 \contentspage {What's New in Qt 4}{Home}
47 \previouspage The Tulip Container Classes
48 \nextpage The Arthur Paint System
49
50 The Interview classes provide a model/view framework for Qt
51 applications based on the well known Model-View-Controller design
52 pattern. In this document, we will describe Qt's model/view
53 architecture, provide some examples, and show the improvements
54 offered over Qt 3's item view classes.
55
56 \tableofcontents
57
58 \section1 Overview of The Model/View Architecture
59
60 The model/view architecture is a variation of the Model-View-Controller
61 (MVC) design pattern, originating from Smalltalk, that is often used when
62 building user interfaces.
63
64 In the model/view architecture, the view and the controller objects are
65 combined. This still separates the way that data is stored from the way
66 that it is presented to the user, but provides a simpler framework based
67 on the same principles. This separation makes it possible to display the
68 same data in several different views, and to implement new types of views,
69 without changing the underlying data structures.
70
71 User input is handled by \e delegates. The advantage of this approach is
72 that it allows rendering and editing of individual items of data to be
73 customized to suit each data type in use.
74
75 \table
76 \row \i \inlineimage modelview-overview.png
77 \i \bold{The model/view architecture}
78
79 The model communicates with a source of data, providing an \e interface
80 for the other components in the architecture. The nature of the
81 communication depends on the type of data source, and the way the model
82 is implemented.
83
84 The view obtains \e{model indexes} from the model; these are references
85 to items of data. By supplying model indexes to the model, the view can
86 retrieve items of data from the data source.
87
88 In standard views, a \e delegate renders the items of data. When an item
89 is edited, the delegate communicates with the model directly using
90 model indexes.
91 \endtable
92
93 \section1 Model/View Classes
94
95 On a fundamental level, the Interview classes define the interfaces and
96 common functionality for models, views, and delegates. All implemented
97 components subclass QAbstractItemModel, QAbstractItemView, or
98 QAbstractItemDelegate. The use of a common API ensures a level of
99 interoperability between the components.
100
101 \image standard-views.png
102
103 Interview provides ready-to-use implementations of views for table,
104 tree, and list widgets: QTableView, QTreeView, and QListView.
105 These standard views are suitable for displaying the most common
106 types of data structures used in applications, and can be used with
107 the ready-made models supplied with Qt:
108
109 \list
110 \o QStandardItemModel is a minimal convenience model that developers
111 can use to manage items of data.
112 \o QDirModel provides directory information for use with QListView and
113 QTreeView.
114 \o QStringListModel is a convenience model that can be used to hold
115 strings for views such as QListView and QComboBox.
116 \endlist
117
118 Two specialized abstract models are provided that can be subclassed
119 and extended (see the
120 \l{model-view-programming.html#related-examples}{Model/View Programming}
121 examples):
122
123 \list
124 \o QAbstractTableModel is a useful starting point for providing a custom
125 model that can be used with QTableView.
126 \o QAbstractListModel can be subclassed to produce a list-based model
127 for use with QListView.
128 \endlist
129
130 Operations on items, such as filtering and sorting, are handled by \e{proxy
131 models} that allow views to display processed data without having to
132 copy or modify data obtained from a source model. Interview provides
133 the QSortFilterProxyModel class to allow items of data from a source model
134 to be sorted and filtered before they are supplied to views.
135
136 Developers who are familiar with the conventional list, tree, and table
137 widgets may find QListWidget, QTreeWidget, and QTableWidget useful.
138 These present a simplified interface to the views that does not require a
139 knowledge of the underlying model/view architecture.
140
141 For details about how to use the model/view classes, see the
142 \l{Model/View Programming} document.
143
144 See also the \l{The Qt 4 Database GUI Layer}{Database GUI Layer} document
145 for information about Qt 4's database models.
146
147 \section1 Example Code
148
149 To illustrate how the Interview classes are used, we present two
150 examples that show different aspects of the model/view architecture.
151
152 \section2 Sharing a Model Between Views
153
154 In this example, we display the contents of a model using two
155 different views, and share the user's selection between
156 them. We will use the QDirModel supplied with Qt because it
157 requires very little configuration, and provides existing data to
158 the views.
159
160 The main() function for this example demonstrates all the
161 principles involved in setting up a model and two views. We also
162 share the selection between the two views:
163
164 \snippet doc/src/snippets/shareddirmodel/main.cpp 1
165
166 In the above function, we construct a directory model to display
167 the contents of a default directory. The two views are constructed
168 and given the same model to work with. By default, each view will
169 maintain and display its own selection of items from the model,
170 so we explicitly create a new selection that is shared between the
171 tree view and the list view. As a result, changes to the selection
172 in either of these views will automatically cause the selection in
173 the other to change.
174
175 \image interview-shareddirmodel.png
176
177 The model/view architecture allows us to replace the QDirModel in
178 this example with a completely different model, one that will perhaps
179 obtain data from a remote server, or from a database.
180
181 \section2 Creating a Custom Model
182
183 In this example, we display items of data obtained from a custom list
184 model using a standard view. The custom model is a subclass of
185 QAbstractListModel and provides implementations of a core set of
186 functions.
187
188 The complete declaration of our model is as follows:
189
190 \snippet doc/src/snippets/stringlistmodel/model.h 0
191 \snippet doc/src/snippets/stringlistmodel/model.h 1
192 \codeline
193 \snippet doc/src/snippets/stringlistmodel/model.h 5
194
195 The model takes a list of strings when constructed, and supplies these
196 to views as required. Since this is only a simple read-only model, we
197 only need to implement a few functions.
198
199 The underlying data structure used to hold the strings is a QStringList.
200 Since the model maps each item in the list to a row in the model, the
201 rowCount() function is quite simple:
202
203 \snippet doc/src/snippets/stringlistmodel/model.cpp 0
204
205 The data() function returns an item of data for each model index
206 supplied by a view:
207
208 \snippet doc/src/snippets/stringlistmodel/model.cpp 1
209
210 The data() function returns a QVariant containing the information
211 referred to by the model index. Items of data are returned to the view,
212 but only if a number of checks are satisfied; for example, if the view
213 specifies an invalid model index, the model indicates this by returning
214 an invalid QVariant.
215
216 Vertical and horizontal headers are supplied by the headerData()
217 function. In this model, the value returned for these items is the row
218 or column number, depending on the header:
219
220 \snippet doc/src/snippets/stringlistmodel/model.cpp 2
221
222 We only include an excerpt from the main() function for this short
223 example:
224
225 \snippet doc/src/snippets/stringlistmodel/main.cpp 1
226 \dots
227 \snippet doc/src/snippets/stringlistmodel/main.cpp 3
228
229 We create a string list to use with the model, and we supply it to the
230 model when it is constructed. The information in the string list is
231 made available to the view via the model.
232
233 \image stringlistmodel.png
234
235 This example shows that it can be easy to populate views with data
236 from a simple model. The standard models and views planned for
237 Qt 4 will make the process even easier, and the convenience widgets
238 supplied provide support for the classic item-based approach.
239
240 \section1 What's Changed Since Qt 3?
241
242 The table and item view classes in Qt 3 implemented widgets that
243 both stored data and presented it to the user. These classes were
244 designed to be easy-to-use and consistent, but were sometimes
245 difficult to customize and extend.
246
247 The equivalent classes in Qt 4 are designed to be extensible while
248 remaining easy-to-use; the introduction of the model/view
249 architecture ensures that they will be more consistent than their
250 predecessors. The view classes provided can be summarized in the
251 following way:
252
253 \list
254 \i QListView class provides a view widget that looks similar to
255 Qt 3's QListBox widget, but displays data provided by a model.
256 It can also be used to display icons in a similar way to Qt 3's
257 QIconView.
258 \i The QTableView class is a view widget that displays tabular data
259 like Qt 3's QTable widget, but uses data provided by a model.
260 \i The QTreeView class provides a view widget that behaves like
261 Qt 3's QListView widget, except that it displays data provided
262 by a model.
263 \endlist
264
265 Since the model takes responsibility for supplying items of data,
266 and the view takes care of their presentation to the user, we do
267 not require item classes to represent individual items.
268 Delegates handle the painting and editing of data obtained from
269 the model.
270
271 Qt continues to provide a number of classic item view widgets with
272 familiar item-based interfaces that are not based on compatibility
273 classes:
274
275 \list
276 \i The QListWidget class provides a widget to display a
277 list of items, as found in Qt 3's QListBox class.
278 \i The QTreeWidget class implements the equivalent of Qt 3's
279 QListView class.
280 \i The QTableWidget class provides comparable functionality to
281 Qt 3's QTable class.
282 \endlist
283
284 Each of the convenience classes have a corresponding item class:
285 QListWidgetItem, QTreeWidgetItem, and QTableWidgetItem are the Qt 4
286 equivalents of Qt 3's QListBoxItem, QListViewItem, and QTableItem
287 respectively.
288
289 The move towards a model/view architecture presents both challenges
290 and opportunities for developers. Although the approach may appear to
291 be rather powerful for simple applications, it encourages greater
292 reuse of components within applications.
293*/
Note: See TracBrowser for help on using the repository browser.