André, I'm just using a QStandardItemModel as the source model and a subclass of QSortFilterProxyModel for the QTreeView mdoel. It seemed simple enough to use QStandardItemModel for the model instead of a custom data structure exposed via a QAbstractItemModel subclass since I don't need anything too complex in terms of storage, etc.
My understanding is I should be using some subclass of QAbstractProxyModel to modify the presentation of the underlying (source) model instead of having special logic in the model itself. At least, that's based on my interpretation of the Qt documentation. In terms of the size/complexity of the model, it can easily have thousands of nodes, several levels deep, and that's just dealing with files we currently support. We're looking at supporting more file types and there's no telling how many nodes/levels users could end up with. That's really why we need a filtering capability in the first place. Thanks, Adam From: Interest [mailto:interest-bounces+thompsonab=ornl....@qt-project.org] On Behalf Of André Somers Sent: Wednesday, September 7, 2016 2:56 AM To: interest@qt-project.org Subject: Re: [Interest] Depth-first filtering for QAbstractProxyModel Op 06/09/2016 om 21:20 schreef Thompson, Adam B.: All, I co-develop an application that uses a QTreeView to display the hierarchical contents of external files. The contents of the tree can become quite a chore to sift through, so I added a means of filtering via a QSortFilterProxyModel. This works as expected, but the user may want to specify a pattern that matches a node deep in the model's structure but not any of the node's ancestors. As such, the breadth-first filtering mechanism provided in QSortFilterProxyModel isn't appropriate for our needs. I modified filterAcceptsRow to work in a depth-first manner to verify my desired filtering effect would work, which it does. However, as expected, it yields a huge performance penalty since it performs a depth-first search for each row in the model. This is because the (recursive) depth-first logic is called for the same nodes many times. I added a crude caching scheme which really doesn't properly mitigate the performance issue. My question: can anyone provide some tips on how to properly subclass QAbstractProxyModel so I can provide some custom depth-first filtering capabilities? (Sorting isn't really necessary at the moment, really just filtering.) Perhaps it is possible to do this in a more efficient way using the underlying data structure instead? That is: make it possible to query each node in your underlying structure directly instead of using the model API to iterate down the tree each time? How big is your model in terms of depth and number of nodes? André
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
