QSortFilterProxyModel¶

PyQt5.QtCore.QSortFilterProxyModel: Inherits from QAbstractProxyModel.

Description¶

The QSortFilterProxyModel class provides support for sorting and filtering data passed between another model and a view.

QSortFilterProxyModel can be used for sorting items, filtering out items, or both. The model transforms the structure of a source model by mapping the model indexes it supplies to new indexes, corresponding to different locations, for views to use. This approach allows a given source model to be restructured as far as views are concerned without requiring any transformations on the underlying data, and without duplicating the data in memory.

Let’s assume that we want to sort and filter the items provided by a custom model. The code to set up the model and the view, without sorting and filtering, would look like this:

#         QTreeView *treeView = new QTreeView;
# #! [0]
#         MyItemModel *model = new MyItemModel(this);

#         treeView->setModel(model);

To add sorting and filtering support to MyItemModel, we need to create a QSortFilterProxyModel, call with the MyItemModel as argument, and install the QSortFilterProxyModel on the view:

#         QTreeView *treeView = new QTreeView;

#         MyItemModel *sourceModel = new MyItemModel(this);
#         QSortFilterProxyModel *proxyModel = new QSortFilterProxyModel(this);

#         proxyModel->setSourceModel(sourceModel);
#         treeView->setModel(proxyModel);

At this point, neither sorting nor filtering is enabled; the original data is displayed in the view. Any changes made through the QSortFilterProxyModel are applied to the original model.

The QSortFilterProxyModel acts as a wrapper for the original model. If you need to convert source QModelIndexes to sorted/filtered model indexes or vice versa, use , , , and .

Note: By default, the model dynamically re-sorts and re-filters data whenever the original model changes. This behavior can be changed by setting the dynamicSortFilter property.

The Basic Sort/Filter Model and Custom Sort/Filter Model examples illustrate how to use QSortFilterProxyModel to perform basic sorting and filtering and how to subclass it to implement custom behavior.

Sorting¶

QTableView and QTreeView have a sortingEnabled property that controls whether the user can sort the view by clicking the view’s horizontal header. For example:

#         treeView->setSortingEnabled(true);

When this feature is on (the default is off), clicking on a header section sorts the items according to that column. By clicking repeatedly, the user can alternate between ascending and descending order.

../../_images/qsortfilterproxymodel-sorting.png

Behind the scene, the view calls the sort() virtual function on the model to reorder the data in the model. To make your data sortable, you can either implement sort() in your model, or use a QSortFilterProxyModel to wrap your model – QSortFilterProxyModel provides a generic sort() reimplementation that operates on the (DisplayRole by default) of the items and that understands several data types, including int, QString, and QDateTime. For hierarchical models, sorting is applied recursively to all child items. String comparisons are case sensitive by default; this can be changed by setting the sortCaseSensitivity property.

Custom sorting behavior is achieved by subclassing QSortFilterProxyModel and reimplementing lessThan(), which is used to compare items. For example:

# bool MySortFilterProxyModel::lessThan(const QModelIndex &left,
#                                       const QModelIndex &right) const
# {
#     QVariant leftData = sourceModel()->data(left);
#     QVariant rightData = sourceModel()->data(right);
# #! [4]

# #! [6]
#     if (leftData.type() == QVariant::DateTime) {
#         return leftData.toDateTime() < rightData.toDateTime();
#     } else {
#         static const QRegularExpression emailPattern("[\\w\\.]*@[\\w\\.]*");

#         QString leftString = leftData.toString();
#         if (left.column() == 1) {
#             const QRegularExpressionMatch match = emailPattern.match(leftString);
#             if (match.hasMatch())
#                 leftString = match.captured(0);
#         }
#         QString rightString = rightData.toString();
#         if (right.column() == 1) {
#             const QRegularExpressionMatch match = emailPattern.match(rightString);
#             if (match.hasMatch())
#                 rightString = match.captured(0);
#         }

#         return QString::localeAwareCompare(leftString, rightString) < 0;
#     }
# }

(This code snippet comes from the Custom Sort/Filter Model example.)

An alternative approach to sorting is to disable sorting on the view and to impose a certain order to the user. This is done by explicitly calling sort() with the desired column and order as arguments on the QSortFilterProxyModel (or on the original model if it implements sort()). For example:

#         proxyModel->sort(2, Qt::AscendingOrder);

QSortFilterProxyModel can be sorted by column -1, in which case it returns to the sort order of the underlying source model.

Filtering¶

In addition to sorting, QSortFilterProxyModel can be used to hide items that do not match a certain filter. The filter is specified using a QRegExp object and is applied to the (DisplayRole by default) of each item, for a given column. The QRegExp object can be used to match a regular expression, a wildcard pattern, or a fixed string. For example:

#         proxyModel->setFilterRegExp(QRegExp(".png", Qt::CaseInsensitive,
#                                             QRegExp::FixedString));
#         proxyModel->setFilterKeyColumn(1);

For hierarchical models, the filter is applied recursively to all children. If a parent item doesn’t match the filter, none of its children will be shown.

A common use case is to let the user specify the filter regular expression, wildcard pattern, or fixed string in a QLineEdit and to connect the textChanged() signal to setFilterRegularExpression(), setFilterWildcard(), or setFilterFixedString() to reapply the filter.

Custom filtering behavior can be achieved by reimplementing the filterAcceptsRow() and filterAcceptsColumn() functions. For example (from the Custom Sort/Filter Model example), the following implementation ignores the filterKeyColumn property and performs filtering on columns 0, 1, and 2:

# bool MySortFilterProxyModel::filterAcceptsRow(int sourceRow,
#         const QModelIndex &sourceParent) const
# {
#     QModelIndex index0 = sourceModel()->index(sourceRow, 0, sourceParent);
#     QModelIndex index1 = sourceModel()->index(sourceRow, 1, sourceParent);
#     QModelIndex index2 = sourceModel()->index(sourceRow, 2, sourceParent);

#     return (sourceModel()->data(index0).toString().contains(filterRegExp())
#             || sourceModel()->data(index1).toString().contains(filterRegExp()))
#             && dateInRange(sourceModel()->data(index2).toDate());
# }

(This code snippet comes from the Custom Sort/Filter Model example.)

If you are working with large amounts of filtering and have to invoke invalidateFilter() repeatedly, using reset() may be more efficient, depending on the implementation of your model. However, reset() returns the proxy model to its original state, losing selection information, and will cause the proxy model to be repopulated.

Subclassing¶

Since QAbstractProxyModel and its subclasses are derived from QAbstractItemModel, much of the same advice about subclassing normal models also applies to proxy models. In addition, it is worth noting that many of the default implementations of functions in this class are written so that they call the equivalent functions in the relevant source model. This simple proxying mechanism may need to be overridden for source models with more complex behavior; for example, if the source model provides a custom hasChildren() implementation, you should also provide one in the proxy model.

Note: Some general guidelines for subclassing models are available in the Model Subclassing Reference.

Note: With Qt 5, regular expression support has been improved through the QRegularExpression class. QSortFilterProxyModel dating back prior to that class creation, it originally supported only QRegExp. Since Qt 5.12, QRegularExpression APIs have been added. Therefore, QRegExp APIs should be considered deprecated and the QRegularExpression version should be used in place.

Warning: Don’t mix calls to the getters and setters of different regexp types as this will lead to unexpected results. For maximum compatibility, the original implementation has been kept. Therefore, if, for example, a call to setFilterRegularExpression is made followed by another one to setFilterFixedString(), the first call will setup a QRegularExpression object to use as filter while the second will setup a QRegExp in FixedString mode. However, this is an implementation detail that might change in the future.

Methods¶

__init__(parent: QObject = None): TODO

buddy(QModelIndex) → QModelIndex: TODO

canFetchMore(QModelIndex) → bool: TODO

columnCount(parent: QModelIndex = QModelIndex()) → int: TODO

data(QModelIndex, role: int = DisplayRole) → Any: TODO

dropMimeData(QMimeData, DropAction, int, int, QModelIndex) → bool: TODO

dynamicSortFilter() → bool: TODO

fetchMore(QModelIndex): TODO

filterAcceptsColumn(int, QModelIndex) → bool: TODO

filterAcceptsRow(int, QModelIndex) → bool: TODO

filterCaseSensitivity() → CaseSensitivity: TODO

filterKeyColumn() → int: TODO

filterRegExp() → QRegExp: See also

setFilterRegExp().

filterRegularExpression() → QRegularExpression: TODO

filterRole() → int: TODO

flags(QModelIndex) → ItemFlags: TODO

hasChildren(parent: QModelIndex = QModelIndex()) → bool: TODO

headerData(int, Orientation, role: int = DisplayRole) → Any: TODO

index(int, int, parent: QModelIndex = QModelIndex()) → QModelIndex: TODO

insertColumns(int, int, parent: QModelIndex = QModelIndex()) → bool: TODO

insertRows(int, int, parent: QModelIndex = QModelIndex()) → bool: TODO

invalidate(): Invalidates the current sorting and filtering.

See also

invalidateFilter().

invalidateFilter()

Invalidates the current filtering.

This function should be called if you are implementing custom filtering (e.g. filterAcceptsRow()), and your filter parameters have changed.