No. You probably do not have to change any of your existing classes. What you need is to derive a QAbstractItemModel that -uses- those classes (and the hierarchy you have built with them) to retrieve the information that will be displayed in your UI.1. Do I need to derive my all classes system,SytemDatabase and CoresData from QAbstractItemModel .
Also no, because your tree does not have a hierarchy like TreeItem -> TreeItem -> TreeItem... where all entries at any level of the tree are the same. In your case, you have System -> SystemDatabase -> CoresData. So, the "parent" item pointer for CoresData should point to the instance of SystemDatabase that owns it, SystemDatabase's parent is System, etc.2. Or Do i need to write like here in the example
And it makes no sense to have a CoresData:: appendChild() method, since those are the leaves of your tree and can't have children. Likewise, SystemDatabase:: appendChild() should add a CoresData child, not a SystemDatabase child. Same for the System class - it has SystemDatabase children.
Your SystemTree class looks good, except I would add the System list as QList< System * > instead of QList< System >. If you define it as QList< System >, then the lifetime of the list entries is defined by the lifetime of the SystemTree - when the SystemTree goes out of scope, the QList and its contents will be deleted. If you define it as QList< System * >, then you can create and manage the System instances independently of the tree model. When the SystemTree goes out of scope, only the QList will be destroyed, not the pointers stored in it.
Bookmarks