How to create artificial nodes in QAbstractItemModel for QTreeView

Question

Hi,

my question is about Qt and its QAbstractItemModel.

I have a map of strings and doubles (std::map<stringclass, double>) which I would like to present in a Qt widget. While I could use QTableView for that, I would like to exploit the fact that the keys of the map are of form "abc.def.ghi" where there can be multiple strings that can start with "abc.def" and even more that start with "abc".

So I would like to setup a tree data model to present the items in a QTreeView like

(-) abc
    |--(-)def      
          |--ghi    3.1415
          |--jkl    42.0815
    |--(+)pqr
    |--(+)xyz

The keys of my std::map are the leaves of the tree, where all other nodes would be temporary and auxillary constructs to support the folding for user convenience.

Unfortunately, the methods rowCount, index, columnCount, and data have const-modifiers, so I cannot simply setup a auxillary data structure for the headers inside my QAbstractItemModel derivate and change that data structure in there.

What would be the best practice for that? Should I setup another class layer between my std::map and the QAbstractItemModel or is there a smarter way to do this?

---

Edit 1: The std::map can change while the QTreeView is shown and used, so the auxillary nodes might be thrown away and reconstructed. My assumption is that the best way to handle this is to restructure the QAbstractItemModel - or should I simply throw that model away and assign a newly constructred one to the QTreeView? In that case I could set-up all nodes within the constructor without being bothered by the const-ness of the methods, I guess.

Answer 1

I don't see how const-modifiers would really be an issue.

What members of your QAbstractItemModel derivate would you want to modify when rowCount, index, columnCount and data methods are called ? You may very well store a reference to your map, and compute everything from it. No need to modify the map itself to extract the needed information (as far as i can tell !).

EDIT after EDIT1 and comments :
If your map is bound to be modified, use it as your base structure in your own class. If you can't keep a reference to your map because the model's lifetime might exceed the map's, use smart pointers to make sure it does not happen.

Answer 2

I would parse the map and create a tree data structure based on it. Make sure you sync the model when you change the map. If this sync step gets too complicated you might want to hold your data in a tree structure from the start and convert to a map when necessary.

Parsing the map on the fly in the model functions seems like a bad idea to me, you'd want these functions to be as fast as possible.