Tree model implementation for C++ data to QML

[xconverge]

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.

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

class Person{
  QString name;
  QString age;
}

class Group{
  QString nickname;
  QString location;
  QList<Person> people;
}

class Classroom{
  QList<Group> groups;
}

To copy to clipboard, switch view to plain text mode 

In use in the backend:

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

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

To copy to clipboard, switch view to plain text mode 

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