In widget my implementation, model the source model (subclassed from a QAbstractItemModel), proxy_model (subclassed from QSortFilterProxyModel) the proxy, and tree (QTreeView) the tree representing the model.
I want to hide the first column.
I tried to use tree.hideColumn(0), the the tree is shown flat.
- If I subclass
filterAcceptsColumnin the proxy to return True only for the second column,, then no rows are shown. I believe this is because the parent/child relationships are anchored on the first column in the indexes, and when the proxy ask for the number of rows for a given index of column 1, the model returns 0 (which is the expected behavior in the model implementation if I understood well). - If I set
rowCountto return non 0 values in the model for columns index > 0, I can see the tree and the rows, but then the model is not passing theQAbstractItemModelTestertest with the folloing error:
qt.modeltest: FAIL! childIndex != childIndex1 () returned FALSE
I understand well that in the tree model, child index must be attached to a single parent index (the first column). But how am I supposed to be hiding the first column in a proxy model if the parent child relationship of the source model are not retained by the proxy if the first column is filtered? I feel it is a "bug" from the proxy, or I missed something !
Do anyone know the proper way of filtering/hiding the first column in the tree view without losing the parent/child information, and still validating a qmodel implementation?
Thanks !
A proper and correct implementation would at least require the proxy to create indexes for the parent of the second column, requiring correct implementation of
index(),parent(),mapToSource()andmapFromSource(). For tree models that can be really tricky.If the source model is not too complex and all its functions are correctly implemented, a possible workaround could be to just override the
data()(andheaderData) of the proxy and always return the sibling of the next column.The following test is done with a simple QStandardItemModel, but I don't think using a QAbstractItemModel should be any different, as long as it's correctly implemented.