As part of making simulation projects more customizable, I would like to make some changes to SMTK so that smtk::project::Project can be a subclass of our PersistentObject class. The motivation is so that I can assign it to a smtk::attribute::ReferenceItem as part of an export-operator specification (attribute). That will let me configure the export operator to the specific project and simulation code before displaying the operator panel.
A summary of the basic changes I plan to make are:
- Remove the pure virtual links() methods from PersistentObject. There is a possibility I will instead have to put placeholder methods in there, but I have not seen any case where I hit the wall by just removing them.
- Move smtk::resource::PersistentObject to the common folder (changing its namespace to smtk::common).
- Change smtk::project::Project to be a subclass of smtk::common::PersistentObject.
- Update ReferenceItem::setObjectValue() to accept any persistent object if its item definition has no “accept” rules.
- Also need to add python bindings for smtk::operator::Operator::configure()
- I might consider updating smtk::attribute::ReferenceItem to write out the UUID of persisent objects that are not Resource or Component entities, depending on how complicated the read-operator side of things has to be. Technically, my use case does not require persistence from ReferenceItem, but serializing and deserializing would seem to be desirable.