diff options
Diffstat (limited to 'doc/src/tutorials/modelview.qdoc')
-rwxr-xr-x | doc/src/tutorials/modelview.qdoc | 938 |
1 files changed, 938 insertions, 0 deletions
diff --git a/doc/src/tutorials/modelview.qdoc b/doc/src/tutorials/modelview.qdoc new file mode 100755 index 0000000..98096a0 --- /dev/null +++ b/doc/src/tutorials/modelview.qdoc @@ -0,0 +1,938 @@ +/**************************************************************************** +** +** 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 documentation of the Qt Toolkit. +** +** $QT_BEGIN_LICENSE:FDL$ +** Commercial Usage +** Licensees holding valid Qt Commercial licenses may use this file in +** accordance with the Qt Commercial License Agreement provided with the +** Software or, alternatively, in accordance with the terms contained in a +** written agreement between you and Nokia. +** +** GNU Free Documentation License +** Alternatively, this file may be used under the terms of the GNU Free +** Documentation License version 1.3 as published by the Free Software +** Foundation and appearing in the file included in the packaging of this +** file. +** +** If you have questions regarding the use of this file, please contact +** Nokia at qt-info@nokia.com. +** $QT_END_LICENSE$ +** +****************************************************************************/ + +/*! + \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. + + \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: + + \list + \o The difference between standard and model/view widgets + \o Adapters betweeen forms and models + \o Developing a simple model/view application + \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. + + \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 + + +*/ + +/*! + \page modelview-part1.html + \contentspage {modelview-index.html}{Model/View Contents} + \previouspage {modelview-index.html}{Model/View Contents} + \nextpage {modelview-part2.html}{Developing a Simple Model/View Application} + \title An Introduction to Model/View Programming + + \section1 1. Introduction + + Model/View is a technology used to separate data from views in widgets that + handle data sets. Standard widgets are not designed for separating data + from views and this is why Qt 4 has two different types of widgets. Both + types of widgets look the same, but they interact with data differently. + + \table + \row + \o Standard widgets use data that is part of the widget. + \o \image standardwidget.png + \row + \o View classes operate on external data (the model) + \o \image modelview.png + \endtable + + \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. + + 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. + + \section2 1.2 Model/View to the Rescue + + Model/view stepped up to provide a solution that uses a more versatile + 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. + + \section2 1.3 Overview of the Model/View Widgets + + Here is an overview of the model/view widgets and their corresponding + standard widgets. + + \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) + \row + \o \inlineimage listview.png + \o \l QListWidget + \o \l QListView + \row + \o \inlineimage tableview.png + \o \l QTableWidget + \o \l QTableView + \row + \o \inlineimage treeview.png + \o \l QTreeWidget + \o \l QTreeView + \row + \o \inlineimage columnview.png + \o + \o \l QColumnView shows a tree as a hierarchy of lists + \row + \o \inlineimage combobox.png + \o {2, 1} \l QComboBox can work as both a view class and also + as a traditional widget + \endtable + + \section2 1.4 Using Adapters between Forms and Models + + 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. + + \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. + + \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. + + \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. + + Below are 7 very simple and independent applications that show different + sides of model/view programming. The source code can be found inside the + \c{examples/tutorials/modelview} directory. + + \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. + + \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: + + \list + \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. + + We have a table data set, so let's start with QAbstractTableModel since it + is easier to use. + + \snippet examples/tutorials/modelview/1_readonly/mymodel.h Quoting ModelView Tutorial + + QAbstractTableModel requires the implementation of three abstract methods. + + \snippet examples/tutorials/modelview/1_readonly/mymodel.cpp Quoting ModelView Tutorial + + The number of rows and columns is set 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. + + 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. + + 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 + demonstrated in section 2.3. + + \section2 2.2 Extending the Read Only Example with Roles + + In addition to controlling what text the view displays, the model also + 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 + checkbox. + Here is the \l{QAbstractItemModel::data()}{data()} method that produces the + result shown above: + + \snippet examples/tutorials/modelview/2_formatting/mymodel.cpp Quoting ModelView Tutorial + + Each formatting property will be requested from the model with a separate + call to the \l{QAbstractItemModel::data()}{data()} method. The \c role + parameter is used to let the model know which property is being requested: + + \table + \header + \o Role (enum Qt::ItemDataRole ) + \o Meaning + \o Type + \row + \o \l{Qt::ItemDataRole}{Qt::DisplayRole} + \o text + \o QString + \row + \o Qt::FontRole + \o font + \o QFont + \row + \o Qt::BackgroundRole + \o brush for the background of the cell + \o QBrush + \row + \o Qt::TextAlignmentRole + \o text alignment + \o enum Qt::AlignmentFlag + \row + \o {1, 3} 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} + \endtable + + Refer to the Qt namespace documentation to learn more about the + Qt::ItemDataRole enum's capabilities. + + Now we need to determine how using a seperated 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. + 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 + available when \l{QAbstractItemModel::}{data()} is invoked and expensive + lookup operations are cached. + + \section2 2.3 A Clock inside a Table Cell + + \image clock.png + + We still have a read only table, but this time the content changes every + second because we are showing the current time. + + \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 + second that the time has changed and that it needs to be read again. We do + this with a timer. In the constructor, we set its interval to 1 second and + connect its timeout signal. + + \snippet examples/tutorials/modelview/3_changingmodel/mymodel.cpp quoting mymodel_a + + Here is the corresponding slot: + + \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()}. + + \section2 2.4 Setting up Headers for Columns and Rows + + Headers can be hidden via a view method: \c{tableView->verticalHeader()->hide();} + \image header.png + + The header content, however, is set via the model, so we reimplement the + \l{QAbstractItemModel::headerData()}{headerData()} method: + + \snippet examples/tutorials/modelview/4_headers/mymodel.cpp quoting mymodel_c + + + \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. + + 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()}. + + \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): + + \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. + 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. + + \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. +*/ + +/*! + \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 + + \section2 3.1 TreeView + + You can convert the example above into an application with a tree view. + 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 + + + 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 + + + This is how our example model looks so far: + \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. + \image tree_2_with_algorithm.png + + \snippet examples/tutorials/modelview/6_treeview/modelview.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 + hierarchical data structure because a QStandardItem can hold other + \l{QStandardItem}{QStandardItems}. Nodes are collapsed and expanded within + the view. + + \section2 3.2 Working with Selections + + 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 + + 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 + \l{QAbstractItemView::}{selectionChanged()} signal. + + \snippet examples/tutorials/modelview/7_selections/modelview.cpp quoting modelview_b + + 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 + \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()}. + + \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. + + \table + \row + \o QStringListModel + \o Stores a list of strings + \row + \o QStandardItemModel + \o Stores arbitrary hierarchical items + \row + \o QFileSystemModel\br + QDirModel + \o Encapsulate the local file system + \row + \o QSqlQueryModel + \o Encapsulate an SQL result set + \row + \o QSqlTableModel + \o Encapsulates an SQL table + \row + \o QSqlRelationalTableModel + \o Encapsulates an SQL table with foreign keys + \row + \o QSortFilterProxyModel + \o Sorts and/or filters another model + + \endtable + + \section2 3.4 Delegates + + In all examples so far, data is presented as text or a checkbox in a cell + 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 + 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: + \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. + + \code + class StarDelegate : public QStyledItemDelegate + { + Q_OBJECT + public: + StarDelegate(QWidget *parent = 0); + void paint(QPainter *painter, const QStyleOptionViewItem &option, + const QModelIndex &index) const; + QSize sizeHint(const QStyleOptionViewItem &option, + const QModelIndex &index) const; + }; + \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. + + 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. + + \section2 3.5 Debugging with ModelTest + + The passive nature of models provides new challenges for programmers. + 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. + + Qt 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. + This is especially important for tree models, since their hierarchical + nature leaves many possibilities for subtle inconsistencies. + + 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 +*/ + +/*! + \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 + + \section2 4.1 Books + + Model/View programming is covered quite extensively in the documentation of + Qt but also in several good books. + + \list 1 + \o \bold{C++ GUI Programming with Qt 4} / Jasmin Blanchette, Mark Summerfield, + \e{Prentice Hall, 2nd edition}, ISBN 0-13-235416-0. Also available in + German: C++ GUI Programmierung mit Qt 4: Die offizielle Einführung, + \e{Addison-Wesley}, ISBN 3-827327-29-6 + \o \bold{The Book of Qt4, The Art of Building Qt Applications} / Daniel Molkentin, + \e{Open Source Press}, ISBN 1-59327-147-6. + Translated from \bold{Qt 4, Einführung in die Applikationsentwicklung}, + \e{Open Source Press}, ISBN 3-937514-12-0. + \o \bold{Foundations of Qt Development} / Johan Thelin, \e{Apress}, ISBN 1-59059-831-8. + \endlist + + More information about these books is available on the + \l{Books about Qt Programming}{Qt Web site}. + + The following list provides an overview of example programs contained in the + books above. Some of them make very good templates for developing similar + applications. + + \table + \header + \o example name + \o view class used + \o model used + \o aspects touched + \o + \row + \o Team Leaders + \o QListview + \o QStringListModel + \o + \o Book 1, Chapter 10, Figure 10.6 + \row + \o Directory Viewer + \o QTreeView + \o QDirModel + \o + \o Book 1, Chapter 10, Figure 10.7 + \row + \o Color Names + \o QListView + \o QSortFilterProxyModel + applied to QStringListModel + \o + \o Book 1, Chapter 10, Figure 10.8 + \row + \o Currencies + \o QTableView + \o custom model based on + QAbstractTableModel + \o read only + \o Book 1, Chapter 10, Figure 10.10 + \row + \o Cities + \o QTableView + \o custom model based on + QAbstractTableModel + \o read / write + \o Book 1, Chapter 10, Figure 10.12 + \row + \o Boolean Parser + \o QTreeView + \o custom model based on + QAbstractItemModel + \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 Book 1, Chapter 10, Figure 10.15 + + \row + \o Four directory views + \o QListView + QTableView + QTreeView + \o QDirModel + \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 + QAbstractTableModel + \o read / write + \o Book2, Chapter 8.4 + \row + \o Address Book with sorting + \o + \o QProxyModel + \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 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 Book2, Chapter 8.7 + \row + \o Address Book with drag and drop + \o + \o + \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 Book2, Chapter 8.9 + \row + \o Views + \o QListView + QTableView + QTreeView + \o QStandardItemModel + \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 Book 3, Chapter 5, figure 5-5 + \row + \o Editdelegate + \o QTableView + \o + \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 + \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 Book 3, Chapter 5, Figure 5-8 + \row + \o treemodel + \o QTreeView + \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 Book 3, Chapter 5, Listing 5-37, Figure 5-11 + \row + \o sorting + \o QTableView + \o QSortFilterProxyModel applied to QStringListModel + \o demonstrates sorting + \o Book 3, Chapter 5, Figure 5-12 + \endtable + + + \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} + \table + \header + \o Example name + \o View class used + \o Model used + \o Aspects touched + \row + \o Address Book + \o QTableView + \o QAbstractTableModel + QSortFilterProxyModel + \o usage of QSortFilterProxyModel to generate different + subsets from one data pool + \row + \o Basic Sort/Filter Model + \o QTreeView + \o QStandardItemModel + QSortFilterProxyModel + \o + \row + \o Chart + \o custom view + \o QStandardItemModel + \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 + \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 + \row + \o Custom Sort/Filter Model + \o QTreeView + \o QStandardItemModel + QSortFilterProxyModel + \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 + \row + \o Editable Tree Model + \o QTreeView + \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 + \row + \o Frozen Column + \o QTableView + \o QStandardItemModel + \o + \row + \o Pixelator + \o QTableView + \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 + \row + \o Simple DOM Model + \o QTreeView + \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 + \row + \o Simple Widget Mapper + \o QDataWidgetMapper to map QLineEdit, QTextEdit and QSpinBox + \o QStandardItemModel + \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 + \row + \o Star Delegate + \o {2, 1} QTableWidget + \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. + + \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 + table view as a spreadsheet, using custom delegates to render + each item according to the type of data it contains. + \endlist + + A \l{Model/View Programming}{reference document} for model/view technology + is also available. +*/ |