Well, index takes row, column and parent, so it should be easy. Thats what you wanted, right?
That is exactly what I thought... until I started coding.
I don't understand the index() method: the arguments over-determine the subject. Whats the meaning of row, column AND parent. Either row/column OR parent is more than enough to devise the index. I don't understand the logic.
The following example does nothing more than QSortFilterProxyModel does with the table. I haven't tried reimplementing AbstractProxyModel yet with this code.
Qt Code:
#ifndef TABLETOTREEPROXYMODEL_H #define TABLETOTREEPROXYMODEL_H //#include <QAbstractProxyModel> #include <QSortFilterProxyModel> #include <QModelIndex> { public: { if (!parent.isValid()) return createIndex(row, 0); else return index(parent.row(),parent.column()+1); return createIndex(row,column); } { return index(child.row(),child.column()-1); } }; #endif // TABLETOTREEPROXYMODEL_HTo copy to clipboard, switch view to plain text mode
Imagine a treeview like so:
#root
#-first tree
#---first tree subitem
#-second tree
#---second tree subitem
So 'first tree' and 'second tree' will require a parent of 'root', whilst the subitems will request the first/second tree as parents as appropriate. Once you have that, THEN you can use the row and column. Without the parent, the row and column are meaningless.
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.
As I understand it, you have
Table(row, column) is the parent of Table(row, column+1)
It would seem to me that all you need to do is iterate through your table, adding items to the tree, in pseudo code this would be:
For row
insert parent
For column
insert child
next column
next row
the number of rows and colums can be obtained from your tableModel:
TableModel->row count();
TableModel->columncount();
the methods for inserting nodes are included in the QTreeWidgetItem class.
Indeed, it’s funny considering the fact that that the model/view was made for easy programming. Or maybe it’s just my bad luck having this problem...
PS: wysota, you have no idea how much I would love to share just a fraction of your insight in this model/view thing! Thanks for trying to solve it.
Bookmarks