Here is a list of things that currently bother me about propertyguizeug's implementation:
Usage of QTreeView
Problem:
QTreeView and the MVC implementation are great … for large tables and simple editors, because they only render what is shown and only create editors when needed, but they are a pain for small lists of properties.
The QAbstractItemModel and QAbstractItemDelegate interfaces needed to be implemented are very rigid and needlessly complicated to comply with (I had to add additional beforeAdd and afterAdd etc. signals to PropertyGroups to react to property additions ...). Moreover, besides implementing just an widget for each type, I also have to implement at least a paint() methods for each type, an additional sizeHint() method would be necessary to make it right.
It is also very tedious to implement the painting right, because once you want to add custom drawing of your types, you have to implement all the default highlighting etc. by yourself. I had to read Qt's source code to make it right and it is still not working as intended.
Implementing #18 is almost out of scope, because the QAbstractItemModel interface is heavily based on indices and dynamically disabling properties would invalidate all indices provided by PropertyGroup, which were added to implement the model in the first place.
Solution: Don't use QTreeView and the MVC framework for properties
Edit 28 Nov 2014:
Using QTreeView also led to the special treatment of std::array properties.
I would like to invite everyone to comment on this and maybe add additional annoyances.
Here is a list of things that currently bother me about propertyguizeug's implementation:
Usage of QTreeView
Problem:
QTreeViewand the MVC implementation are great … for large tables and simple editors, because they only render what is shown and only create editors when needed, but they are a pain for small lists of properties.The
QAbstractItemModelandQAbstractItemDelegateinterfaces needed to be implemented are very rigid and needlessly complicated to comply with (I had to add additional beforeAdd and afterAdd etc. signals to PropertyGroups to react to property additions ...). Moreover, besides implementing just an widget for each type, I also have to implement at least apaint()methods for each type, an additionalsizeHint()method would be necessary to make it right.It is also very tedious to implement the painting right, because once you want to add custom drawing of your types, you have to implement all the default highlighting etc. by yourself. I had to read Qt's source code to make it right and it is still not working as intended.
Implementing #18 is almost out of scope, because the
QAbstractItemModelinterface is heavily based on indices and dynamically disabling properties would invalidate all indices provided byPropertyGroup, which were added to implement the model in the first place.Solution: Don't use
QTreeViewand the MVC framework for propertiesEdit 28 Nov 2014: Using
QTreeViewalso led to the special treatment ofstd::arrayproperties.I would like to invite everyone to comment on this and maybe add additional annoyances.