Tree model implementation for C++ data to QML

I have been going through this example and was looking for another shove in the right direction if possible :) The example is o-so-close to being exactly what I need but the different derived types instead of all being an Item* is messing me up a bit.

https://doc.qt.io/qt-5/qtwidgets-ite...l-example.html

I have a datastructure on the C++ side that I will be modifying and updating (from the C++ side as well mostly). I plan on using this as the model for my views on the QML side. I don't necessarily need to use a listview or anything that will specifically need the data formatted in a certain way, but I do need access to all of this data on the QML side.

Code:

---

class Person{
  QString name;
  QString age;
}
 
class Group{
  QString nickname;
  QString location;
  QList<Person> people;
}
 
class Classroom{
  QList<Group> groups;
}

---

In use in the backend:

Code:

---

QScopedPointer<Classroom> model(new Classroom);
qmlRegisterSingletonInstance("Classroom", 1, 0, "Classroom", model.get());

---

1. So far, I have started down the route of making the Classroom derive from QAbstractItemModel (can this be a list model since there is only 1 column?)
2. I have made group and person, QObjects, and then store pointers to them inside the relevant parent classes. Should the middle item, "Group" derive from a QAbstractItemModel as well or does the top level "Classroom" as a model cover this layer/level and the layer below..
3. Should I use QVariantList instead and write my own notify signals, this doesn't seem right but I can wrap my head around it a bit better, so I am trying to go the right performant/model route
4. I do not plan on writing to this model from the qml side, I might fire off a few signals that "impact" the model from the c++ side, which will then in turn cause a change in the view
5. Should I skip the model, and just make them all qobjects with properties of all of the child items (including qlist<Qobject*>) to get what I want from the top level item, an instance of Classroom?
6. Roles are really just to make navigation easier from the qml side, right?


Sorry for all of the questions, I have just been running in circles a bit here and am looking for a bit of guidance.

The below threads (along with many others) are getting me there but I wanted to take a stab at getting a push in the right direction for my own use case

https://www.qtcentre.org/threads/706...tractListModel
https://www.qtcentre.org/threads/397...el-for-dummies

I have found that it is best to -not- try to convert a hierarchical data structure directly into a hierarchical QAbstractItemModel (if I interpret your statement "making the Classroom derive from QAbstractItemModel" correctly).

Instead derive a "ClassroomModel" (say) from QAbstractItemModel and store a pointer to your Classroom singleton in it as a data member. Then, you can devise a way to store something in each QModelIndex that uniquely identifies where that index is in the hierarchy. It could be an integer that represents where that node is in a traversal through the hierarchy (0 is the Classroom node, 1 is the first Group node, 2 is the first Person node in the first Group, 3 is the second Person node in that Group, etc.) It could be a void pointer to the Group or Person node. Anything that lets you map from a QModelIndex into your actual data structure.

In any case, I think you will find the need for a back-pointer from Person to Group or "groupId" members in Person and Group so you can tell which Group a Person belongs to. You will need this in order to implement the model's parent() method.

The point of roles is so that a view can interrogate the model about how to customize the display of each member of the model. The only one you truly need to implement is the DisplayRole, since that provides the string that is used to display that item in the view. But there are many other roles which can be used to customize the appearance and which the view will ask for as it draws each item. You could have icons that are different for Classroom, Group, and Person nodes, different text or background colors, something other than the default left alignments, etc.

Identity proxies are an interesting way to display the same base model in different ways in different views by using a different identity model for each view. It is in the identity model where the "decorations" get added (for icon, color, alignment, etc. roles) and the base model simply satisfies the DisplayRole.

Interesting, that makes sense to me along with some of the advice you gave here! https://www.qtcentre.org/threads/706...tractListModel

Perhaps me trying to combine them into my existing data structure classes is contributing to my confusion and when I separate it out, things will start to make some more sense. I was putting them into my existing classes just for simplicity during the prototyping phase, but perhaps it is throwing me off of what I actually need to do to implement my model indices.

Basically you are suggesting just create somewhat of a linked list implementation of my data structure, and then use a unique identifier for every single node, that then each map to a unique modelindex within ClassroomModel and thus also gets exposed to my QML view.

I continue to wonder if this is really the best way to accomplish what seems like it should have a simpler solution (just properties for each member at each level since they are all qobjects?), but I see that sentiment in quite a few of the other similar threads to mine :) Your suggestion is starting to circle in on another idea I was starting to have which was to just have a whole pile of pointers that go into a hash table with some way of accessing them, and the way you are suggesting seems similar (using modelindex and the predefined model interface to solve the access problem)

I take the name literally: QAbstractItemModel: it is an abstraction of some underlying data structure that acts as a well-defined interface between that data structure and a visualization of that data structure in a user interface. The view interacts with the model, the model interacts with the data structure. There is no need to rewrite the view when the data structure changes because the model-view interface doesn't change.

I've used hash tables / maps, linked lists, vectors, a Tree class where the actual data for each node is stored in a void pointer data member and all the tree structure does is provide the parent-child links for navigation. The Tree class might work well for your problem, since all you have is a simple hierarchy.

Each Tree node could contain a "node type" enum (ClassroomType, GroupType, PersonType) which would tell you how to cast the void pointer to an actual class instance pointer. When your underlying data changes, you simply destroy the whole tree and rebuild it (bracketed by calls to beginResetModel() and endResetModel()). The pointer to the Tree node is stored in the QModelIndex's internal data pointer.

Code:

---

struct Tree
{
   Tree * parent = nullptr;
   QList< Tree * > children;
   int nodeType = -1;
   void *  nodeData = nullptr;
 
   ~Tree()
   {
        for ( child : children)
            delete child;
   }
};
 
QModelIndex MyModel::index( int row, int column, const QModelIndex & parent ) const
{
    QModelIndex newIndex;
    if ( parent.isValid() )
    {
        if ( row >= 0 && row < rowCount( parent ) && column >= 0 && column < columnCount( parent ) )
        {
              Tree * parentNode = static_cast< Tree * >( parent.internalPointer() );
              Tree * childNode = parentNode->children[ row ];
              newIndex = createIndex( row, column, (void *)childNode );
        }
    }
    return newIndex;
}
 
QVariant MyModel::data( const QModelIndex & index, int role ) const
{
    QVariant returnVal;
    if ( index.isValid() && role == Qt::DisplayRole )
    {
        Tree * node = static_cast< Tree * >( index.internalPointer() );
        switch( node->nodeType )
        {
             case ClassroomType:
                  returnVal = "Classroom";
              break;
 
             case GroupType:
             {
                  Group * group = static_cast< Group * >(node->nodeData);
                  returnVal = group->name;
             }
             break;
 
            // etc.
        }
    }
    return returnVal;
}

---

If the underlying data structure has multiple "columns", then the data() method will have to map from a column number to a field in the data structure; for example column 0 of a Group node would be the group name, column 1 the location. You just need to expand each clause of the switch statement to retrieve the column data.

I hope that I don't end up hitting a wall with the need to beginResetModel/endResetModel to update the entire model and thus probably the entire view if just a single element in a child of a child is changed, I don't think this will be an issue for my application (5-10 persons per 1-5 groups, per 1 classroom), but it is worth thinking about. Just because I am new to QML (not new to Qt necessarily), you allude to the shortcut/less maintainable version that piqued my interest, that does not adhere/implement the abstract interface. Would that be a QObject with properties and invokable functions? If I were to go that route, I would get a change notification per property potentially, and be more performant than the original suggestion, wouldn't I? The downside as you mentioned is maintainability of the interface between the model and the view.

The view is basically going to be a classroom view, with a tabview of groups, and in each tab a rowlayout of persons

Thanks for your replies, I really appreciate it!

Quote:

---

I don't think this will be an issue for my application (5-10 persons per 1-5 groups, per 1 classroom)

---

No. I use a similar structure for a tree with one root element, 5 top level elements under that, and 10 - 15 children under each of those. Rebuilding the tree and re-displaying it when something changes is instantaneous.

I don't see any advantage in using QObject as a base class for anything in the data structure; if you did, you'd have to change it from QList< whatever > to QList< whatever * > since QObject doesn't allow copy or assignment semantics.

I am a big believer in clean data structures that are not encumbered by a particular framework (like Qt), so I tend to lean towards straight C++ / STL to represent them. If I need to have an editable data structure, then I will devise an editor class that -is- Qt-based so that I can have that class manage the changes to the data structure and send signals to the rest of the UI to make updates.

I help maintain a large library of data and algorithm classes that is entirely written in vanilla C++ / STL. It is used in both Qt and MFC applications on Windows, as well as in Qt applications on linux, OS/X, and android platforms. It's probably close to a half-million lines of code. So keeping things clean and portable is a big part of what I've learned to do.

Quote:

---

Originally Posted by d_stranz

No. I use a similar structure for a tree with one root element, 5 top level elements under that, and 10 - 15 children under each of those. Rebuilding the tree and re-displaying it when something changes is instantaneous.

I don't see any advantage in using QObject as a base class for anything in the data structure; if you did, you'd have to change it from QList< whatever > to QList< whatever * > since QObject doesn't allow copy or assignment semantics.

I am a big believer in clean data structures that are not encumbered by a particular framework (like Qt), so I tend to lean towards straight C++ / STL to represent them. If I need to have an editable data structure, then I will devise an editor class that -is- Qt-based so that I can have that class manage the changes to the data structure and send signals to the rest of the UI to make updates.

I help maintain a large library of data and algorithm classes that is entirely written in vanilla C++ / STL. It is used in both Qt and MFC applications on Windows, as well as in Qt applications on linux, OS/X, and android platforms. It's probably close to a half-million lines of code. So keeping things clean and portable is a big part of what I've learned to do.

---

That is great empirical info on the performance front, thanks

I planned on using vanilla/stl for the data structures on the backend elsewhere to avoid pulling in the qt dependencies and was going to write a translation layer into the qobject versions, so removing that extra level of abstraction for no reason is going to be helpful and makes a lot of sense!

If set up this way, what would the pseudocode of the qml look like to access the first person in the first group of the classroom look like from my ClassroomModel singleton?

I will take a crack at it with this new mindset/plan and report back, thanks a bunch!

Quote:

---

what would the pseudocode of the qml look like

---

Well, there's where you've reached the limit of my knowledge. I've never written any serious code using the QML / QtQuick framework. Everything I do is QWidget-based desktop apps.

Maybe someone else with more experience can jump in.

So I was able to get a prototype working that looks something like this (warning: pretty far from the implementation idea discussed so far). This prototype captures the simplicity of how I "thought" things should be able to work, so at least now I don't feel crazy. I by no means think this is the right or best way though, but that is mentioned at the bottom of this post

Code:

---

class Person : public QObject {
  Q_OBJECT
  Q_PROPERTY(QString name MEMBER m_name)
  Q_PROPERTY(int age MEMBER m_age)
 public:
  explicit Person(Group* parent = nullptr);
  explicit Person(const QString& name, int age, Group* parent = nullptr);
 
 private:
  QString m_name = "";
  int m_age;
};
 
class Group : public QObject {
  Q_OBJECT
  Q_PROPERTY(QString nickname MEMBER m_nickname)
 public:
  explicit Group(Classroom* parent = nullptr);
  explicit Group(QString nickname, Classroom* parent = nullptr);
  ~Group();
 
  void appendPerson(Person* person);
  Q_INVOKABLE QObject* person(int index);
  int personCount() const;
 signals:
  void personCountChanged();
 
 private:
  QString m_nickname;
  QList<Person*> m_people;
};
 
class Classroom: public QObject {
  Q_OBJECT
  Q_PROPERTY(int groupCount READ groupCount NOTIFY groupCountChanged)
 public:
  Classroom(QObject* parent = nullptr);
  ~Classroom();
 
  void appendGroup(Group* group);
 
  Q_INVOKABLE QObject* getGroup(int index) const;
  int groupCount() const;
 signals:
  void groupCountChanged();
 
 private:
  // Temp debug code to populate the model
  void populateModel();
 
  QList<Group*> m_groups;
};

---

and then in QML I am able to access it with stuff like this:

Code:

---

console.log(ClassroomModel.getGroup(groupNum).person(1).name);

---

or with a property

Code:

---

property int groupCount: ClassroomModel.groupCount

---

I think I understand the tradeoffs between using this vs subclassing a qabstractmodel, but wanted to put my thoughts on these explicitly incase there is something I am missing

1) My datastructures are QObjects, not raw clean c++/stl, so a translation layer will be needed if I want to use raw stl structures on the backend to populate the model
2) I wrote a custom interface, and my view code will need to be updated more often than if I were to have used the interface from qabstractmodel
3) I can put in notify signals wherever I want really at any layer
4) Performance as you said doesn't seem to be bad to do a complete destroy/recreate of my view with the number of items I am talking, but there is room here to optimize using some smarter notify/change signals
5) Not compatible with tableview/etc as is, but can be used for Repeater counts and anything else where an exposed property would suffice
6) I can even use this https://doc.qt.io/qt-5/qtqml-cppinte...ect-list-types to simplify the API even more

This looks like it is going to work for my application, but I would love to hear about any counterpoints (either the same as what I identified above, or different/new)

I was really struggling with modelindex and how it could work for me, but that could always be a refactor/change I tackle in the future.