Well if you think about why I did that, it’s only and only because the dynamic behaviour of different “nodes” and node properties
A light has properties a transform doesn’t, and a camera has stuff a light doesn’t, and they all have different amount of attributes with different types
The model view framework is built for data layout of the same type and same layout across all objects, so setData in the nodes was done just because of this. I would take a completely different approach to the entire thing to be completely honest. I don’t like the model view framework for property type stuff since it can be so dynamic.
Sure there are ways around, you can wrap a QAbstractItemModel and a QItemDelegate in your own class and make sure it returns widgets depending on the data type and data count but it just makes everything so much more complex.
Because of that I didn’t want to bloat the model with different behaviour, the model view framework in Qt is good for data layouts that is same across all nodes, which wasn’t our case. Besides I would never watch a tutorial and take everything for granted, I’m usually doing my own research as well, and so should you!
Since everything is done on the fly during the tutorial I really didn’t sit and software design
But I would probably have some sort of a
Property (holds tooltips, value, string value)
PropertyManager(creates properties, need to derive this for each data type, aka BoolManager)
PropertyFactory (creates the editable widgets, need to derive this for each data type aka CheckBoxFactory)
PropertyBrowser (the populated browser, so register a manager for a factory here, derive it GroupPropertyBrowser or TreePropertyBrowser etc)
and leave the model view framework for what it’s good for, displaying objects
Be aware that the naming is not perfect and I just wrote it fast, I usually don’t name stuff “manager” because it tends to make it unclear what the class role is