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
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:
int m_age;
};
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:
QList<Person*> m_people;
};
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.
Tree model implementation for C++ data to QML
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.
Reply With Quote
Originally Posted by d_stranz
Bookmarks