1 /****************************************************************************
3 ** Copyright (C) 2011 Nokia Corporation and/or its subsidiary(-ies).
4 ** All rights reserved.
5 ** Contact: Nokia Corporation (qt-info@nokia.com)
7 ** This file is part of the documentation of the Qt Toolkit.
9 ** $QT_BEGIN_LICENSE:FDL$
10 ** GNU Free Documentation License
11 ** Alternatively, this file may be used under the terms of the GNU Free
12 ** Documentation License version 1.3 as published by the Free Software
13 ** Foundation and appearing in the file included in the packaging of
17 ** Alternatively, this file may be used in accordance with the terms
18 ** and conditions contained in a signed written agreement between you
26 ****************************************************************************/
31 \startpage {index.html}{Qt Reference Documentation}
33 \title Model/View Tutorial
34 \brief An introduction to ModelView programming
36 Every UI developer should know about ModelView programming and the goal of
37 this tutorial is to provide you with an easily understandable introduction
40 Table, list and tree widgets are components frequently used in GUIs. There
41 are 2 different ways how these widgets can access their data. The
42 traditional way involves widgets which include internal containers for
43 storing data. This approach is very intuitive, however, in many non-trivial
44 applications, it leads to data synchronization issues.
45 The second approach is model/view programming, in
46 which widgets do not maintain internal data containers. They access external
47 data through a standardized interface and therefore avoid data duplication.
48 This may seem complicated at first, but once you take a closer look, it is
49 not only easy to grasp, but the many benefits of model/view programming also
54 In the process, we will learn about some basic technologies provided by Qt,
58 \o The difference between standard and model/view widgets
59 \o Adapters betweeen forms and models
60 \o Developing a simple model/view application
62 \o Intermediate topics such as:
67 \o Debugging with model test
71 You will also learn whether your new application can be written easier with
72 model/view programming or if classic widgets will work just as well.
74 This tutorial includes example code for you to edit and integrate into your
75 project. The tutorial's source code is located in Qt's
76 \c examples/tutorials/modelview directory.
78 For more detailed information you may also want to look at the
79 \l{model-view-programming.html}{reference documentation}
81 If you are completely new to Qt, please read \l{How to Learn Qt} if you
82 have not already done so.
85 \section1 1. Introduction
87 Model/View is a technology used to separate data from views in widgets that
88 handle data sets. Standard widgets are not designed for separating data
89 from views and this is why Qt 4 has two different types of widgets. Both
90 types of widgets look the same, but they interact with data differently.
94 \o Standard widgets use data that is part of the widget.
95 \o \image standardwidget.png
97 \o View classes operate on external data (the model)
98 \o \image modelview.png
101 \section2 1.1 Standard Widgets
103 Let's have a closer look at a standard table widget. A table widget is a 2D
104 array of the data elements that the user can change. The table widget can be
105 integrated into a program flow by reading and writing the data elements that
106 the table widget provides.
107 This method is very intuitive and useful in many applications, but displaying
108 and editing a database table with a standard table widget can be problematic.
109 Two copies of the data have to be coordinated: one outside the
110 widget; one inside the widget. The developer is responsible for
111 synchronizing both versions. Besides this, the tight coupling of presentation and data
112 makes it harder to write unit tests.
114 \section2 1.2 Model/View to the Rescue
116 Model/view stepped up to provide a solution that uses a more versatile
117 architecture. Model/view eliminates the data consistency problems that may
118 occur with standard widgets. Model/view also makes it easier to use more
119 than one view of the same data because one model can be passed on to many
120 views. The most important difference is that model/view widgets do not store
121 data behind the table cells. In fact, they operate directly from your data.
122 Since view classes do not know your data's structure, you need to provide a
123 wrapper to make your data conform to the QAbstractItemModel interface. A
124 view uses this interface to read from and write to your data. Any instance
125 of a class that implements QAbstractItemModel is said to be a model. Once
126 the view receives a pointer to a model, it will read and display its content
129 \section2 1.3 Overview of the Model/View Widgets
131 Here is an overview of the model/view widgets and their corresponding
137 \o Standard Widget\br
138 (an item based convenience class)
139 \o Model/View View Class\br
140 (for use with external data)
142 \o \inlineimage listview.png
146 \o \inlineimage tableview.png
150 \o \inlineimage treeview.png
154 \o \inlineimage columnview.png
156 \o \l QColumnView shows a tree as a hierarchy of lists
158 \o \inlineimage modelview-combobox.png
159 \o {2, 1} \l QComboBox can work as both a view class and also
160 as a traditional widget
163 \section2 1.4 Using Adapters between Forms and Models
165 Having adapters between forms and models can come in handy.
167 We can edit data stored in tables directly from within the table itself, but
168 it's much more comfortable to edit data in text fields. There is no direct
169 model/view counterpart that separates data and views for widgets that
170 operate on one value (QLineEdit, QCheckBox ...) instead of a dataset, so we
171 need an adapter in order to connect the form to the source of data.
173 \l QDataWidgetMapper is a great solution because it maps form widgets to a
174 table row and makes it very easy to build forms for database tables.
176 \image widgetmapper.png
178 Another example of an adapter is \l QCompleter. Qt has \l QCompleter for
179 providing auto-completions in Qt widgets such as \l QComboBox and, as shown
180 below, \l QLineEdit. \l QCompleter uses a model as its data source.
182 \image qcompleter.png
185 \section1 2. A Simple Model/View Application
186 If you want to develop a model/view application, where should you start?
187 We recommend starting with a simple example and extending it step-by-step.
188 This makes understanding the architecture a lot easier. Trying to understand
189 the model/view architecture in detail before invoking the IDE has proven
190 to be less convenient for many developers. It is substantially easier to
191 start with a simple model/view application that has demo data. Give it a
192 try! Simply replace the data in the examples below with your own.
194 Below are 7 very simple and independent applications that show different
195 sides of model/view programming. The source code can be found inside the
196 \c{examples/tutorials/modelview} directory.
198 \section2 2.1 A Read Only Table
200 We start with an application that uses a QTableView to show data. We will
201 add editing capabilities later.
203 (file source: examples/tutorials/modelview/1_readonly/main.cpp)
204 \snippet examples/tutorials/modelview/1_readonly/main.cpp Quoting ModelView Tutorial
206 We have the usual \l {modelview-part2-main-cpp.html}{main()} function:
208 Here is the interesting part: We create an instance of MyModel and use
209 \l{QTableView::setModel()}{tableView.setModel(&myModel);} to pass a
210 pointer of it to to \l{QTableView}{tableView}. \l{QTableView}{tableView}
211 will invoke the methods of the pointer it has received to find out two
215 \o How many rows and columns should be displayed.
216 \o What content should be printed into each cell.
219 The model needs some code to respond to this.
221 We have a table data set, so let's start with QAbstractTableModel since it
222 is easier to use than the more general QAbstractItemModel.
224 (file source: examples/tutorials/modelview/1_readonly/mymodel.h)
225 \snippet examples/tutorials/modelview/1_readonly/mymodel.h Quoting ModelView Tutorial
227 QAbstractTableModel requires the implementation of three abstract methods.
229 (file source: examples/tutorials/modelview/1_readonly/mymodel.cpp)
230 \snippet examples/tutorials/modelview/1_readonly/mymodel.cpp Quoting ModelView Tutorial
232 The number of rows and columns is provided by
233 \l{QAbstractItemModel::rowCount()}{MyModel::rowCount()} and
234 \l{QAbstractItemModel::columnCount()}{MyModel::columnCount()}. When the view
235 has to know what the cell's text is, it calls the method
236 \l{QAbstractItemModel::data()}{MyModel::data()}. Row and column information
237 is specified with parameter \c index and the role is set to
238 \l{Qt::ItemDataRole}{Qt::DisplayRole}. Other roles are covered in the next
239 section. In our example, the data that should be displayed is generated. In
240 a real application, \c MyModel would have a member called \c MyData, which
241 serves as the target for all reading and writing operations.
243 This small example demonstrates the passive nature of a model. The model
244 does not know when it will be used or which data is needed. It simply
245 provides data each time the view requests it.
247 What happens when the model's data needs to be changed? How does the view
248 realize that data has changed and needs to be read again? The model has to
249 emit a signal that indicates what range of cells has changed. This will be
250 demonstrated in section 2.3.
252 \section2 2.2 Extending the Read Only Example with Roles
254 In addition to controlling what text the view displays, the model also
255 controls the text's appearance. When we slightly change the model, we get
256 the following result: \image readonlytable_role.png
258 In fact, nothing except for the \l{QAbstractItemModel::}{data()} method
259 needs to be changed to set fonts, background colour, alignment and a
261 Below is the \l{QAbstractItemModel::data()}{data()} method that produces the
262 result shown above. The difference is that this time we use parameter int
263 role to return different pieces of information depending on its value.
265 (file source: examples/tutorials/modelview/2_formatting/mymodel.cpp)
266 \snippet examples/tutorials/modelview/2_formatting/mymodel.cpp Quoting ModelView Tutorial
268 Each formatting property will be requested from the model with a separate
269 call to the \l{QAbstractItemModel::data()}{data()} method. The \c role
270 parameter is used to let the model know which property is being requested:
274 \o \l{Qt::ItemDataRole}{enum Qt::ItemDataRole}
278 \o \l{Qt::ItemDataRole}{}Qt::DisplayRole
282 \o \l{Qt::ItemDataRole}{Qt::FontRole}
286 \o \l{Qt::ItemDataRole}{BackgroundRole}
287 \o brush for the background of the cell
290 \o \l{Qt::ItemDataRole}{Qt::TextAlignmentRole}
292 \o \l{Qt::AlignmentFlag}{enum Qt::AlignmentFlag}
294 \o {1, 3} \l{Qt::ItemDataRole}{Qt::CheckStateRole}
295 \o {1, 3} suppresses checkboxes with \l{QVariant}{QVariant()},
297 sets checkboxes with \l{Qt::CheckState}{Qt::Checked}
299 or \l{Qt::CheckState}{Qt::Unchecked}
300 \o {1, 3} \l{Qt::ItemDataRole}{enum Qt::ItemDataRole}
303 Refer to the Qt namespace documentation to learn more about the
304 \l{Qt::ItemDataRole}{Qt::ItemDataRole} enum's capabilities.
306 Now we need to determine how using a separated model impacts the
307 application's performance, so let's trace how often the view calls the
308 \l{QAbstractItemModel::}{data()} method. In order to track how often the
309 view calls the model, we have put a debug statement in the
310 \l{QAbstractItemModel::}{data()} method, which logs onto the error output
311 stream. In our small example, \l{QAbstractItemModel::}{data()} will be
313 Each time you hover the cursor over the field,
314 \l{QAbstractItemModel::}{data()} will be called again \mdash 7 times for
315 each cell. That's why it is important to make sure that your data is
316 available when \l{QAbstractItemModel::}{data()} is invoked and expensive
317 lookup operations are cached.
319 \section2 2.3 A Clock inside a Table Cell
323 We still have a read only table, but this time the content changes every
324 second because we are showing the current time.
326 (file source: examples/tutorials/modelview/3_changingmodel/mymodel.cpp)
327 \snippet examples/tutorials/modelview/3_changingmodel/mymodel.cpp quoting mymodel_QVariant
329 Something is missing to make the clock tick. We need to tell the view every
330 second that the time has changed and that it needs to be read again. We do
331 this with a timer. In the constructor, we set its interval to 1 second and
332 connect its timeout signal.
334 (file source: examples/tutorials/modelview/3_changingmodel/mymodel.cpp)
335 \snippet examples/tutorials/modelview/3_changingmodel/mymodel.cpp quoting mymodel_a
337 Here is the corresponding slot:
339 (file source: examples/tutorials/modelview/3_changingmodel/mymodel.cpp)
340 \snippet examples/tutorials/modelview/3_changingmodel/mymodel.cpp quoting mymodel_b
342 We ask the view to read the data in the top left cell again by emitting the
343 \l{QAbstractItemModel::}{dataChanged()} signal. Note that we did not
344 explicitly connect the \l{QAbstractItemModel::}{dataChanged()} signal to the
345 view. This happened automatically when we called \l{QTableView::}{setModel()}.
347 \section2 2.4 Setting up Headers for Columns and Rows
349 Headers can be hidden via a view method: \c{tableView->verticalHeader()->hide();}
350 \image modelview-header.png
352 The header content, however, is set via the model, so we reimplement the
353 \l{QAbstractItemModel::headerData()}{headerData()} method:
355 (file source: examples/tutorials/modelview/4_headers/mymodel.cpp)
356 \snippet examples/tutorials/modelview/4_headers/mymodel.cpp quoting mymodel_c
358 Note that method \l{QAbstractItemModel::headerData()}{headerData()} also has
359 a parameter role which has the same meaning as in
360 \l{QAbstractItemModel::data()}{MyModel::data()}.
362 \section2 2.5 The Minimal Editing Example
364 In this example, we are going to build an application that automatically
365 populates a window title with content by repeating values entered into table
366 cells. To be able to access the window title easily we put the QTableView in
369 The model decides whether editing capabilities are available. We only have
370 to modify the model in order for the available editing capabilities to be
371 enabled. This is done by reimplementing the following virtual methods:
372 \l{QAbstractItemModel::}{setData()} and \l{QAbstractItemModel::}{flags()}.
374 (file source: examples/tutorials/modelview/5_edit/mymodel.h)
375 \snippet examples/tutorials/modelview/5_edit/mymodel.h Quoting ModelView Tutorial
377 We use \c the two-dimensional array QString \c m_gridData to store our data.
378 This makes \c m_gridData the core of \c MyModel. The rest of \c MyModel acts
379 like a wrapper and adapts \c m_gridData to the QAbstractItemModel
380 interface. We have also introduced the \c editCompleted() signal, which
381 makes it possible to transfer the modified text to the window title.
383 (file source: examples/tutorials/modelview/5_edit/mymodel.cpp)
384 \snippet examples/tutorials/modelview/5_edit/mymodel.cpp quoting mymodel_e
386 \l{QAbstractItemModel::setData()}{setData()} will be called each time the
387 user edits a cell. The \c index parameter tells us which field has been
388 edited and \c value provides the result of the editing process. The role
389 will always be set to \l Qt::EditRole because our cells only contain text.
390 If a checkbox were present and user permissions are set to allow the
391 checkbox to be selected, calls would also be made with the role set to
392 \l Qt::CheckStateRole.
394 (file source: examples/tutorials/modelview/5_edit/mymodel.cpp)
395 \snippet examples/tutorials/modelview/5_edit/mymodel.cpp quoting mymodel_f
397 Various properties of a cell can be adjusted with
398 \l{QAbstractItemModel::flags()}{flags()}.
400 Returning \l{Qt::ItemFlag}{Qt::ItemIsSelectable | Qt::ItemIsEditable | Qt::ItemIsEnabled}
401 is enough to show an editor that a cell can be selected.
403 If editing one cell modifies more data than the data in that particular
404 cell, the model must emit a \l{QAbstractItemModel::}{dataChanged()} signal
405 in order for the data that has been changed to be read.
408 \section1 3. Intermediate Topics
410 \section2 3.1 TreeView
412 You can convert the example above into an application with a tree view.
413 Simply replace QTableView with QTreeView, which results in a read/write
414 tree. No changes have to be made to the model. The tree won't have any
415 hierarchies because there aren't any hierarchies in the model itself.
417 \image dummy_tree.png
419 QListView, QTableView and QTreeView all use a model abstraction, which is a
420 merged list, table and tree. This makes it possible to use several different
421 types of view classes from the same model.
423 \image list_table_tree.png
425 This is how our example model looks so far:
427 \image example_model.png
429 We want to present a real tree. We have wrapped our data in the examples
430 above in order to make a model. This time we use QStandardItemModel, which
431 is a container for hierarchical data that also implements
432 QAbstractItemModel. To show a tree, QStandardItemModel must be populated
433 with \l{QStandardItem}s, which are able to hold all the standard properties
434 of items like text, fonts, checkboxes or brushes.
436 \image tree_2_with_algorithm.png
438 (file source: examples/tutorials/modelview/6_treeview/mainwindow.cpp)
439 \snippet examples/tutorials/modelview/6_treeview/mainwindow.cpp Quoting ModelView Tutorial
441 We simply instantiate a QStandardItemModel and add a couple of
442 \l{QStandardItem}{QStandardItems} to the constructor. We can then make a
443 hierarchical data structure because a QStandardItem can hold other
444 \l{QStandardItem}{QStandardItems}. Nodes are collapsed and expanded within
447 \section2 3.2 Working with Selections
449 We want to access a selected item's content in order to output it into the
450 window title together with the hierarchy level.
452 \image selection2.png
454 So let's create a couple of items:
456 (file source: examples/tutorials/modelview/7_selections/mainwindow.cpp)
457 \snippet examples/tutorials/modelview/7_selections/mainwindow.cpp quoting modelview_a
459 Views manage selections within a separate selection model, which can be
460 retrieved with the \l{QAbstractItemView::}{selectionModel()} method. We
461 retrieve the selection Model in order to connect a slot to its
462 \l{QAbstractItemView::}{selectionChanged()} signal.
464 (file source: examples/tutorials/modelview/7_selections/mainwindow.cpp)
465 \snippet examples/tutorials/modelview/7_selections/mainwindow.cpp quoting modelview_b
467 We get the model index that corresponds to the selection by calling
468 \l{QItemSelectionModel::currentIndex()}{treeView->selectionModel()->currentIndex()}
469 and we get the the field's string by using the model index. Then we just
470 calculate the item's \c hierarchyLevel. Top level items do not have parents
471 and the \l{QAbstractItemModel::}{parent()} method will return a default
472 constructed \l{QModelIndex}{QModelIndex()}. This is why we use the
473 \l{QAbstractItemModel::}{parent()} method to iterate to the top level while
474 counting the steps performed during iteration.
476 The selection model (as shown above) can be retrieved, but it can also be
477 set with \l{QAbstractItemView}{QAbstractItemView::setSelectionModel}. This
478 is how it's possible to have 3 view classes with synchronised selections
479 because only one instance of a selection model is used. To share a selection
480 model between 3 views use \l{QAbstractItemView::}{selectionModel()} and
481 assign the result to the second and third view class with
482 \l{QAbstractItemView::}{setSelectionModel()}.
484 \section2 3.3 Predefined Models
486 The typical way to use model/view is to wrap specific data to make it usable
487 with view classes. Qt, however, also provides predefined models for common
488 underlying data structures. If one of the available data structures is
489 suitable for your application, a predefined model can be a good choice.
494 \o Stores a list of strings
496 \o QStandardItemModel
497 \o Stores arbitrary hierarchical items
499 \o QFileSystemModel\br
501 \o Encapsulate the local file system
504 \o Encapsulate an SQL result set
507 \o Encapsulates an SQL table
509 \o QSqlRelationalTableModel
510 \o Encapsulates an SQL table with foreign keys
512 \o QSortFilterProxyModel
513 \o Sorts and/or filters another model
517 \section2 3.4 Delegates
519 In all examples so far, data is presented as text or a checkbox in a cell
520 and is edited as text or a checkbox. The component that provides these
521 presentation and editing services is called a \e delegate. We are only just
522 beginning to work with the delegate because the view uses a default
523 delegate. But imagine that we want to have a different editor (e.g., a
524 slider or a drop down list) Or imagine that we want to present data as
526 Let's take a look at an example called \l{Star Delegate Example}{Star
527 Delegate}, in which stars are used to show a rating:
529 \image stardelegate.png
531 The view has a \l{QAbstractItemView::}{setItemDelegate()} method that
532 replaces the default delegate and installs a custom delegate.
533 A new delegate can be written by creating a class that inherits from
534 QStyledItemDelegate. In order to write a delegate that displays stars and
535 has no input capabilities, we only need to override 2 methods.
538 class StarDelegate : public QStyledItemDelegate
542 StarDelegate(QWidget *parent = 0);
543 void paint(QPainter *painter, const QStyleOptionViewItem &option,
544 const QModelIndex &index) const;
545 QSize sizeHint(const QStyleOptionViewItem &option,
546 const QModelIndex &index) const;
550 \l{QStyledItemDelegate::}{paint()} draws stars depending on the content of
551 the underlying data. The data can be looked up by calling
552 \l{QModelIndex::data()}{index.data()}. The delegate's
553 \l{QAbstractItemDelegate::}{sizeHint()} method is used to obtain each
554 star's dimensions, so the the cell will provide enough height and width to
555 accommodate the stars.
557 Writing custom delegates is the right choice if you want to show your data
558 with a custom graphical representation inside the grid of the view class. If
559 you want to leave the grid, you would not use a custom delegate but a custom
562 Other references to delegates in Qt Documentation:
565 \o \l{Spin Box Delegate Example}
566 \o \l{QAbstractItemDelegate}{QAbstractItemDelegate Class Reference}
567 \o \l{QSqlRelationalDelegate}{QSqlRelationalDelegate Class Reference}
568 \o \l{QStyledItemDelegate}{QStyledItemDelegate Class Reference}
569 \o \l{QItemDelegate}{QItemDelegate Class Reference}
573 \section2 3.5 Debugging with ModelTest
575 The passive nature of models provides new challenges for programmers.
576 Inconsistencies in the model can cause the application to crash. Since the
577 model is hit by numerous calls from the view, it is hard to find out which
578 call has crashed the application and which operation has introduced the
581 Qt Labs provides software called
582 \l{http://labs.qt.nokia.com/page/Projects/Itemview/Modeltest}{ModelTest},
583 which checks models while your programming is running. Every time the model
584 is changed, ModelTest scans the model and reports errors with an assert.
585 This is especially important for tree models, since their hierarchical
586 nature leaves many possibilities for subtle inconsistencies.
588 Unlike view classes, ModelTest uses out of range indexes to test the model.
589 This means your application may crash with ModelTest even if it runs
590 perfectly without it. So you also need to handle all of the indexes that are
591 out of range when using ModelTest.
594 \section1 4. Good Sources of Additional Information
598 Model/View programming is covered quite extensively in the documentation of
599 Qt but also in several good books.
602 \o \bold{C++ GUI Programming with Qt 4} / Jasmin Blanchette, Mark Summerfield,
603 \e{Prentice Hall, 2nd edition}, ISBN 0-13-235416-0. Also available in
604 German: \bold{C++ GUI Programmierung mit Qt 4: Die offizielle Einführung},
605 \e{Addison-Wesley}, ISBN 3-827327-29-6
606 \o \bold{The Book of Qt4, The Art of Building Qt Applications} / Daniel Molkentin,
607 \e{Open Source Press}, ISBN 1-59327-147-6.
608 Translated from \bold{Qt 4, Einführung in die Applikationsentwicklung},
609 \e{Open Source Press}, ISBN 3-937514-12-0.
610 \o \bold{Foundations of Qt Development} / Johan Thelin, \e{Apress}, ISBN 1-59059-831-8.
611 \o \bold{Advanced Qt Programming} / Mark Summerfield, \e{Prentice Hall}, ISBN 0-321-63590-6.
612 This book covers Model/View programming on more than 150 pages.
615 More information about these books is available on the
616 \l{Books about Qt Programming}{Qt Web site}.
618 The following list provides an overview of example programs contained in the first three
619 books listed above. Some of them make very good templates for developing similar
634 \o Book 1, Chapter 10, Figure 10.6
640 \o Book 1, Chapter 10, Figure 10.7
644 \o QSortFilterProxyModel
645 applied to QStringListModel
647 \o Book 1, Chapter 10, Figure 10.8
651 \o custom model based on
654 \o Book 1, Chapter 10, Figure 10.10
658 \o Custom model based on
661 \o Book 1, Chapter 10, Figure 10.12
665 \o Custom model based on
668 \o Book 1, Chapter 10, Figure 10.14
671 \o {2, 1} QTableWidget
672 \o Custom delegate providing a custom editor
673 \o Book 1, Chapter 10, Figure 10.15
676 \o Four directory views
681 \o Demonstrates the use of multiple views
682 \o Book2, Chapter 8.2
688 \o Custom model based on
691 \o Book2, Chapter 8.4
693 \o Address Book with sorting
696 \o Introducing sort and filter capabilities
697 \o Book2, Chapter 8.5
703 \o Introducing checkboxes in model/view
704 \o Book2, Chapter 8.6
706 \o Address Book with transposed grid
708 \o Custom proxy Model based on QAbstractProxyModel
709 \o Introducing a custom model
710 \o Book2, Chapter 8.7
712 \o Address Book with drag and drop
715 \o Introducing drag and drop support
716 \o Book2, Chapter 8.8
718 \o Address Book with custom editor
721 \o Introducing custom delegates
722 \o Book2, Chapter 8.9
728 \o QStandardItemModel
730 \o Book 3, Chapter 5, figure 5-3
735 \o Custom delegate for presentation based on QAbstractItemDelegate
736 \o Book 3, Chapter 5, figure 5-5
741 \o Custom delegate for editing based on QAbstractItemDelegate
742 \o Book 3, Chapter 5, figure 5-6
745 \o Custom view based on QAbstractItemView
754 \o Custom Model based on QAbstractTableModel
756 \o Book 3, Chapter 5, Figure 5-8
760 \o Custom Model based on QAbstractItemModel
762 \o Book 3, Chapter 5, Figure 5-10
766 \o Custom Model based on QAbstractListModel
768 \o Book 3, Chapter 5, Listing 5-37, Figure 5-11
772 \o QSortFilterProxyModel applied to QStringListModel
773 \o Demonstrates sorting
774 \o Book 3, Chapter 5, Figure 5-12
778 \section2 4.2 Qt Documentation
780 Qt 5.0 comes with 19 examples for model/view.
781 The examples can be found on the \l{Item Views Examples} page.
792 \o QAbstractTableModel
793 QSortFilterProxyModel
794 \o Usage of QSortFilterProxyModel to generate different
795 subsets from one data pool
797 \o Basic Sort/Filter Model
799 \o QStandardItemModel
800 QSortFilterProxyModel
805 \o QStandardItemModel
806 \o Designing custom views that cooperate with selection models
808 \o Color Editor Factory
809 \o {2, 1} QTableWidget
810 \o Enhancing the standard delegate with a new custom editor to choose colours
812 \o Combo Widget Mapper
813 \o QDataWidgetMapper to map QLineEdit, QTextEdit and QComboBox
814 \o QStandardItemModel
815 \o Shows how a QComboBox can serve as a view class
817 \o Custom Sort/Filter Model
819 \o QStandardItemModel
820 QSortFilterProxyModel
821 \o Subclass QSortFilterProxyModel for advanced sorting and filtering
826 \o Very small example to demonstrate how to assign a model to a view
828 \o Editable Tree Model
831 \o Comprehensive example for working with trees, demonstrates
832 editing cells and tree structure with an underlying custom
838 \o Dynamically changing model
842 \o QStandardItemModel
852 \o Custom table model
853 \o Implementation of a custom delegate
858 \o Model/view with drag and drop
863 \o Read only example for a custom tree model
868 \o Read only example for a custom tree model
870 \o Simple Widget Mapper
871 \o QDataWidgetMapper to map QLineEdit, QTextEdit and QSpinBox
872 \o QStandardItemModel
873 \o Basic QDataWidgetMapper usage
877 \o QStandardItemModel
878 \o Custom delegate that uses a spin box as a cell editor
885 \o {2, 1} QTableWidget
886 \o Comprehensive custom delegate example.
889 A \l{Model/View Programming}{reference document} for model/view technology
894 \page modelview-part2-main-cpp.html
896 \quotefile tutorials/modelview/1_readonly/main.cpp