From cd621c201ca637385c6e3409d5c84ecec5fb5418 Mon Sep 17 00:00:00 2001 From: Casper van Donderen Date: Fri, 16 Sep 2011 14:14:43 +0200 Subject: Move the module qdoc files from qtdoc and split up doc/src. Change-Id: I7d992889379d78e07a0b7023facebd7421cf6d22 Reviewed-on: http://codereview.qt-project.org/5092 Reviewed-by: Qt Sanity Bot Reviewed-by: Jerome Pasion --- doc/src/tutorials/modelview.qdoc | 897 --------------------------------------- 1 file changed, 897 deletions(-) delete mode 100644 doc/src/tutorials/modelview.qdoc (limited to 'doc/src/tutorials/modelview.qdoc') diff --git a/doc/src/tutorials/modelview.qdoc b/doc/src/tutorials/modelview.qdoc deleted file mode 100644 index 9cbba47b60..0000000000 --- a/doc/src/tutorials/modelview.qdoc +++ /dev/null @@ -1,897 +0,0 @@ -/**************************************************************************** -** -** Copyright (C) 2011 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$ -** 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. -** -** Other Usage -** Alternatively, this file may be used in accordance with the terms -** and conditions contained in a signed written agreement between you -** and Nokia. -** -** -** -** -** $QT_END_LICENSE$ -** -****************************************************************************/ - -/*! - \page modelview.html - \ingroup tutorials - \startpage {index.html}{Qt Reference Documentation} - - \title Model/View Tutorial - \brief An introduction to ModelView programming - - 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 - - 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 Predefined models - \o Intermediate topics such as: - \list - \o Tree views - \o Selection - \o Delegates - \o Debugging with model test - \endlist - \endlist - - 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. - - 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. - - - \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, but 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 is responsible for - synchronizing both versions. Besides this, 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. 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 - - Here is an overview of the model/view widgets and their corresponding - standard widgets. - - \table - \header - \o Widget - \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 - \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 modelview-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 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 makes it very easy to build forms for database tables. - - \image widgetmapper.png - - 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 - - - \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. - - (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: - - 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. - \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 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 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 - \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. - - 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 - - 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. - 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 - 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 \l{Qt::ItemDataRole}{enum Qt::ItemDataRole} - \o Meaning - \o Type - \row - \o \l{Qt::ItemDataRole}{}Qt::DisplayRole - \o text - \o QString - \row - \o \l{Qt::ItemDataRole}{Qt::FontRole} - \o font - \o QFont - \row - \o \l{Qt::ItemDataRole}{BackgroundRole} - \o brush for the background of the cell - \o QBrush - \row - \o \l{Qt::ItemDataRole}{Qt::TextAlignmentRole} - \o text alignment - \o \l{Qt::AlignmentFlag}{enum Qt::AlignmentFlag} - \row - \o {1, 3} \l{Qt::ItemDataRole}{Qt::CheckStateRole} - \o {1, 3} suppresses checkboxes with \l{QVariant}{QVariant()}, - - 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 - \l{Qt::ItemDataRole}{Qt::ItemDataRole} enum's capabilities. - - 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 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 - 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. - - (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 - 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. - - (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()}. - - \section2 2.4 Setting up Headers for Columns and Rows - - Headers can be hidden via a view method: \c{tableView->verticalHeader()->hide();} - \image modelview-header.png - - 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. 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 - 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 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 \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 - \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 \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. - - - \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}s, which are able to hold all the standard properties - of items like text, fonts, checkboxes or brushes. - - \image tree_2_with_algorithm.png - - (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 - 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: - - (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 - \l{QAbstractItemView::}{selectionChanged()} signal. - - (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 - \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. 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. - - \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 \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); - 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 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 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 - - 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 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. - 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. - - - \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: \bold{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. - \o \bold{Advanced Qt Programming} / Mark Summerfield, \e{Prentice Hall}, ISBN 0-321-63590-6. - This book covers Model/View programming on more than 150 pages. - \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 first three - books listed 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 covered - \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 5.0 comes with 19 examples for model/view. - 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 covered - \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 Interview - \o Multiple - \o Custom item model - \o Multiple views - \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 Spreadsheet - \o {2, 1} QTableView - \o Custom delegates - \row - \o Star Delegate - \o {2, 1} QTableWidget - \o Comprehensive custom delegate example. - \endtable - - 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 -*/ -- cgit v1.2.3