Here is something interesting: from QAbstractItemModel Class Reference for “parent()â€:
[…] A common convention used in models that expose tree data structures is that only items in the first column have children. For that case, when reimplementing this function in a subclass the column of the returned QModelIndex would be 0.[...]
The meaning of “conventions†is left open: which implications has it on the model? Same with “would beâ€: is it an option or a necessity to make it 0?
In the end, I really feel like wasting time. In the meantime I could have written 50 classic trees, so to speak. The Qt Model/View documentation doesn't say anything about Model-View interaction. It just says what you should implement for certain thing to occur, and let the magic work, and if magic fails, then one's only option is to delve into the sourcecode and try to figure out the internal workings.
Up till now, I tried many things. They outcomes/debuggings all lack logic to me. And in the end, I don't even see why one would need pointers to make trees. It seems an unnecessary complication. Why? Because the underlying Model/View structure is represented in tables in the first place, and because trees are representable as graphs (with constraints), and the two structures (one could probably argue) are completely isomorphic, given the constraints. (There are books written about this, mainly for the practical purpose of translating the (old) hierarchical databases into the relational ones.)
I'll just use the TreeItem and TreeModel for my implementation, of simply the QTreeWidget..
Thanks for your help anyway.
Bookmarks