How to implement tree model?

[Mingun]

In the previous versions of QtJambi (when it was in com.trolltech.qt package) there was a QTreeModel class, written specially for QtJambi, because it is hard to implement Qt tree model in Java. But that class is absent in https://doc.qtjambi.io/ nowadays.

What the replacement of this class? How to implement custom tree models? Where I can find documentation for that version of QtJambi (4.x I suppose)?

[omix]

The QtJambi4 class QTreeModel did nothing, you could not also realize in Java. Modern QtJambi reduces the set of available API classes to existing counterparts in Qt.
Be inspired by legacy code of QTreeModel to recreate it in Java if you will:

https://github.com/OmixVisualization/qtjambi4/blob/master/src/cpp/qtjambi_gui/qtreemodel.h
https://github.com/OmixVisualization/qtjambi4/blob/master/src/cpp/qtjambi_gui/qtreemodel.cpp

[Mingun]

The QtJambi4 class QTreeModel did nothing, you could not also realize in Java.

To clarify: this phrase is not my invention, somehow it was written in the QtJambi4 documentation, which explains why the intermediate class is needed. One argument was that it is hard to support hierarchical structure of QModelIndex, because you cannot use Java object addresses for that, and the QModelIndex does not provide an API to store reference to Java object -- it accepts only long argument in createIndex call. So it's a bit tricky to implement tree model in idiomatic Java way.

Be inspired by legacy code of QTreeModel to recreate it in Java if you will:

Thanks! I somehow missed the source code of the 4th version of QtJambi. I suppose, there is no more hosted documentation for that version?

[omix]

To clarify: this phrase is not my invention, somehow it was written in the QtJambi4 documentation, which explains why the intermediate class is needed. One argument was that it is hard to support hierarchical structure of QModelIndex, because you cannot use Java object addresses for that, and the QModelIndex does not provide an API to store reference to Java object -- it accepts only long argument in createIndex call. So it's a bit tricky to implement tree model in idiomatic Java way.

Ok, I never knew this. Actually, I used tree models in QtJambi since 2007 and I never used QTreeModel. I realized it by using QStandardItemModel. I created QStandardItems for the root and each child level.

If you want to use the internalId field of QModelIndex for Java objects, you additionally need a map for the ids and objects, e.g. TreeMap<Long,Object>. The map stores the tree elements and their long-value identifiers. That's nearly the same as the QtJambi4 QTreeModel class did with Node. There, you have the objects with their hash values aligned in a vector. The objectes are kept by global references and released when deleting the QTreeModel. All of this is possible in Java.

[omix]

Thanks! I somehow missed the source code of the 4th version of QtJambi. I suppose, there is no more hosted documentation for that version?

I stopped maintenance in 2016. I don't think there is still any documentation about it. In the days of Qt6, there is no much attention on this project.

[Mingun]

I created QStandardItems for the root and each child level.

Yes, that is the one possible way, but in some cases it cannot be used correctly, especially if all that you want is to represent existing data structure in the Qt tree. You should be very carefully by working with internals of your actual data structure inside the methods that can be called as slots, connected to model / view signals. For example, when you delete child from QStandardItemModel, it emits both signals, rowsAboutToBeRemoved and rowsRemoved and you have no chance to modify your actual data between that events, that violates the Qt requirements.

One consequence of the removal is that selectionChanged signal of QItemSelectionModel can be triggered in between of these emits, and if you accesses your internal data directly in a slot, connected to this signal, you can get surprising results. These are rather non-obvious consequences.

Probably in that case you can connected itself to QStandardItemModel signals, but I cannot remember, is Qt guaranties some specific order of calling slots, and even if so, it is hard to guarantee that your slot will be called first / last.

So, in some cases implementation of your own TreeModel is the only right way :)