Small issue with #182 is that the data widget mapper uses Qt::EditRole for bool fields. We have to support the role for those fields in the data method again. Also the preview areas are using our custom ProtoModel::Data method which was returning the Qt::DisplayRole for fields. I do not believe that was what we intended as the Qt::DisplayRole is supposed to be the stringified data for display. Not only does the Qt::EditRole fix the path preview for smooth/closed it seems to be technically more correct since it returns appropriately typed data.
Although Qt::EditRole is also documented as technically returning a QString, everything seems to be fine as before. I tested around quite a bit and the path preview is back to normal and everything. Perhaps later if we do anymore specialization and end up hitting a wall, we could consider creating our own custom role for returning the typed data.
Small issue with #182 is that the data widget mapper uses
Qt::EditRole
for bool fields. We have to support the role for those fields in the data method again. Also the preview areas are using our customProtoModel::Data
method which was returning theQt::DisplayRole
for fields. I do not believe that was what we intended as the Qt::DisplayRole is supposed to be the stringified data for display. Not only does theQt::EditRole
fix the path preview for smooth/closed it seems to be technically more correct since it returns appropriately typed data.Although
Qt::EditRole
is also documented as technically returning a QString, everything seems to be fine as before. I tested around quite a bit and the path preview is back to normal and everything. Perhaps later if we do anymore specialization and end up hitting a wall, we could consider creating our own custom role for returning the typed data.