Extended attribute modeling is one of the things that came up in the SMTK 3.1/4.0 planning topic:
I’m starting this discussion to work out the implications of some of the alternative designs below. Note that they are not mutually exclusive.
Variant 1: Extensible Items (and ItemDefinitions)
Being able to subclass
smtk::attribute::Item would allow people to model more complex constraints, to have functor-like item values, and to add additional constraints to attributes – such as closer ties between model entities and values stored on them. This would involve the following changes
- Replace the
smtk::attribute::Item::Typeenum with something like
size_tvalue that hashes each subclass’s type name).
- We could also allow subclasses of Attribute to implement application-specific logic/constraints. In hydrology, bed layers might be a candidate for this.
Each Item and ItemDefinition would be required to
- serialize/deserialize itself, which could cause problems with versioning.
- implement its own GUI representation, which could be a lot of work.
Variant 2: All attribute edits must be operations
Any changes to attributes would be required to use the operation framework. This would allow changes to be monitored via the operation manager (assuming one is used) and could thus signal user interface components to respond. The operation system would allow complex constraints (via observers). Unlike Variant 1, the constraints would not need to be local to the new item class.
A twist on this would be to allow some items to “be operations.” In this case, an item might compute its value (say, the mass properties of some associated model entities) rather than be assigned values by a user.
- By forcing users to rely on the operation system’s observers (and thus relying on having an operation manager), the usual observer-responder problems could exist but they might also be limited in scope because the operation framework might be used to track operations and detect cycles.
Variant 3: Observers (a.k.a. Crazy Town)
All (or at least most) methods in the current attribute system that make changes would emit changes as they occurred to any observers that care to monitor them.
There are a lot:
- debugging observers/responders can be difficult since the call stack can be unpredictable.
- fragile/brittle, since observers don’t know of other observers and/or ordering of responders
- unexpected behaviors can result from interactions between responses to the same event
- threaded/asynchronous operations could make it problematic for observers that need to be invoked on a specific thread (i.e., specifically the GUI thread).
Variant 4: Special cases
Rather than trying to satisfy a large set of requirements, we could adopt a number of smaller, targeted solutions to specific problems brought up by use cases:
- One common use case (RGG, IBAMR, …) was operations that need to update their parameters (attributes) as changes are made to the set of associated model/mesh entities. We could add a method to
configure()that would be called by the application (GUI or script) to give operations a chance to update their parameters (or their defaults). This would let us pass default bounds to ParaView widgets that make sense for a given context.
- We might not get everything we want and yet be stuck with a lot of maintenance problems where small changes create corner cases that must be handled.
In addition to the changes above to deal with extending the functionality of items, we will allow categories to be assigned directly to attributes. Child attributes/items with categories assigned will “percolate” up to views so that all of the categories appear in the “limit view by category” combo box.