Simple TreeView based on a ListModel & a separator

swurl

I already have a ListView and a ListModel properly set up. However, the data in the model needs to be separated into a tree, as the data itself is separated by slashes (e.g. /RootItem/ChildItem). Is there a simple way to "convert" the ListModel data into a TreeView with proper separation based on the slashes?

swurl

Switching to a QStandardItemModel seemed to work just fine, it makes handling of parent/child easy.

VRonin

If the model is built in C++ (or Python) then you can use a QAbstarctProxyModel subclass to implement it, if it's built in QML then I'm afraid you need to rebuild a separate model manually

swurl

It's built in C++. Moreso what I'm asking is how I would be able to split things up into a tree based on an existing C++ model. The ProxyModel documentation is pretty sorely lacking.

VRonin

That’s an abstract class, the docs can’t tell you how to implement custom stuff. See https://doc.qt.io/qt-6/model-view-programming.html for a more in-depth explanation

Bob64

I think a QAbstractProxyModel needs a QAbstractItemModel as a source. In other words, it is not a means to adapt something like a QAbstractListModel to a QAbstractItemModel.

If @swurl is starting with a list model, I think they will need to write their own adaptor that implements QAbstractItemModel as this is the model type needed for a tree view.

VRonin

@Bob64 said in Simple TreeView based on a ListModel & a separator:

it is not a means to adapt something like a QAbstractListModel to a QAbstractItemModel.

that's exactly what it's meant to do

JonB

@Bob64 said in Simple TreeView based on a ListModel & a separator:

it is not a means to adapt something like a QAbstractListModel to a QAbstractItemModel.

As @VRonin has written. Are you aware that QAbstractListModel derives from QAbstractItemModel so it does need "adapting", it already is one?

swurl

Switching to a QStandardItemModel seemed to work just fine, it makes handling of parent/child easy.

Bob64

@JonB said in Simple TreeView based on a ListModel & a separator:

As @VRonin has written. Are you aware that QAbstractListModel derives from QAbstractItemModel so it does need "adapting", it already is one?

Yes I am aware - or at least I should be - so I am not sure what I was thinking there!

It is possible that my thinking was influenced by another thought I was having, that a list model like this does not necessarily directly map to a tree. I am recalling similar things I have worked with where the list contains only paths to leaf nodes. It seems like mapFromSource/mapToSource kind of assumes a one-to-one mapping, in which case I think that sort of list model would need to be expanded to an intermediate list model that adds in interior nodes as rows.

JonB

@Bob64
I'm sorry I don't know how this relates to your list model. But in the case of a tree model, for a tree view display, a Qt tree model will need to have nodes as well as the leaves.

Bob64

@JonB sorry I wasn't clear. I was thinking of something that regularly cropped up in some past projects where we had to transform lists of path-like data into tree models. Consider a list of paths that are all of this form:

/path/to/leaf

Even though the list only contains entries to leaves, there is certainly sufficient information in the data to infer a tree structure, but I don't think the proxy would allow one to map a list model of this form directly to a tree model.

Anyway, this was what was in my mind and what was colouring my response to the question. Apologies if I caused any confusion.

JonB

@Bob64
If you have leaf /path/to/leaf to be split on /s at some level you will have to create/return/treat as existing nodes /, /path and /path/to as well as leaf /path/to/leaf in order to keep Qt tree model/view code happy.

You have two basic approaches:

Actually split all your strings into necessary nodes & leaves into their own model (e.g. a QStandardItemModel can be thus populated and is ready for you to use). This obviously means a separate representation/storage for the tree model compared to wherever you store the strings/list model.
You could do it with a proxy model which has the strings as the underlying data but you would have to parse them each time, do the splitting temporarily/dynamically in memory and return the appropriate nodes, leaves and counts of children as Qt queries the model. That would mean only the strings were permanently maintained.

The second case might be wanted if the strings change frequently or you want changes in the tree model to reflect directly to underlying strings. But the second case is probably easier to write and works fine if the tree model/strings not not change.