Tree model implementation for C++ data to QML

[xconverge]

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

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;
};

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;
};

To copy to clipboard, switch view to plain text mode 

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

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

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

To copy to clipboard, switch view to plain text mode 

or with a property

property int groupCount: ClassroomModel.groupCount

property int groupCount: ClassroomModel.groupCount

To copy to clipboard, switch view to plain text mode 

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.