Announcing the Release of SMTK 23.01

We are pleased to announce the release of SMTK 23.01. We will summarize some of the import features in 23.01 as well as those in 22.11 which due to an oversight was not blogged previously.

Extended Resource Locking

Now any caller (not just the base Operation class) can acquire resource locks via a new smtk::resource::ScopedLockSetGuard class. It has static Block() and Try() methods which accept a set of resources to read-lock and a set of resources to write-lock. The method named Block() blocks until the locks are acquired (Note: this may cause deadlocks if you are not careful). The method named Try() does not block but may return a null pointer to a ScopedLockSetGuard. If either method returns a non-null pointer, the referenced object’s destructor releases all the locks. In no event will only a subset of resources be locked.

Changes to SMTK Attribute Resource

Enhancing the Ability to Copy and Assign SMTK Attributes and Items

SMTK provided an initial mechanism for copying and assigning both Attributes and Items. In 22.11 we deprecated the old API and replaced it with a more flexible design. Both smtk::attribute::Attribute::copyAttribute and smtk::attribute::Attribute::assign methods now take in the following:

• The source Attribute to be copied or assigned frrom
• CopyAndAssignmentOptions instance
• Logger instance

The CopyAndAssignmentOption class controls how Attributes are copied and how information gets assigned. It contains three subclasses of information:

• Attribute Copying Options which include if the copied attribute should have the same UUID as the original (for example we could be creating an updated version of the Attribute in a different Resource. It also indicates if the the Definition associated with the Attribute to be copied should also be copied if it doesn’t exist.
• Attribute Assignment Options which are used during Attribute assignments. It can indicates if it’s permissible that not all of the source Attribute’s Items be found in the target Attribute. This can happen if the copy and target Attributes are of different versions. It controls how the source Attribute’s association information will get transferred to the target Attribute.
• Item Assignment Options which are used during Item assignments.Similar to the Attribute Assignment Options, these options indicate if it’s permissible that not all of the source Item’s children Items be found in the target Item. It can also indicate how ValueItem’s expressions and ReferenceItem values can get assigned and if it is permitted to copy the Attributes they are referencing.

The new smtk::Item::assign method is similar to the Attribute::assign method with the exception that it takes in a source Item to be assigned from.

We have also removed the assumption that both the target and source must have their Items in the same order so that a newer version of an Attribute or Item Definition are free to reorganize their internal Item Definitions.

Introducing the Attribute Update Manager

The attribute system now has an update manager to aid in migrating resources from one schema version (i.e., template) to another. As part of this change, each attribute resource now has a templateType() and a templateVersion() method to identify the schema from which it is derived. The values are provided by the SimBuilder Template (SBT) file used as the prototype for the resource. Workflow designers should update template files with a template type and version in order to support future migration.

Enhancing ItemBlock Support in Attribute Template Files

Previously ItemBlocks were file-scope only. SMTL 23.01 extends ItemBlocks so that an ItemBlock defined in one file can be consumed by another file that includes it. To maintain backward compatibility, an ItemBlock that is to be exported must include the Export XML attribute and be set to true.

In order to better organize ItemBlocks, SMTK 23.01 now supports the concept of Namespaces. To indicate an ItemBlock is defined with a specific Namespace NS, you will need to use the Namespace XML attribute. As a shortcut, if all of the ItemBlocks in a file are to belong to the same Namespace, you can specify the Namespace XML attribute at the ItemBlocks level as well. If no Namespace is specified, SMTK assumes the ItemBlock belongs to the global Namespace represented by “”.

Note: Namespaces are only used w/r ItemBlocks and can not be nested.

Changed to SMTK Operations

We have introduced a new way to invoke an operation: rather than calling operate(), which returns a result, you should either launch an operation or invoke safeOperate() which accepts a functor that will be evaluated on the result. The method itself returns only the operation’s outcome. This is done to prevent crashes or undefined behavior (that can occur if you inspect the result without holding locks on all the involved resources). The handler (if you pass one) is invoked before the operation releases resource locks. Note that safeOperate() blocks until the operation is complete and should not be invoked on the main thread of a GUI application since it can cause deadlocks.

Markup operation for ontology tagging

The markup resource now provides a “Tag Individual” operation for users to tag nodes, marking them as instances of an ontology class (i.e., tagging them as named individuals). If you have an ontology authored in the web ontology language (OWL) – or write your own in YAML and convert it to OWL – you can import it and use this operation to tag nodes. In the future, we plan to provide more access to the ontology to support reasoning about relationships between tagged nodes. Note that SMTK does not provide an ontology by default, but aeva provides the Uberon ontology.

Python Related Changes

In the past, each time you ran modelbuilder and wanted to use an operation written in Python, you would have to use the “File→Import Operation…” menu item to register the operation. Now you can add a small block to the bottom of your python module and load it as a plugin in modelbuilder. See the documentation for more details.

Qt Related Changes

Enhancements to qtFileItem

The QFileDialog created by qtFileItem now includes an “All supported types” entry as the first set of file extensions when a smtk::attribute::FileItemDefinition is marked to accept existing files. On many platforms, this simplifies browsing since users no longer have to select a specific file-type of interest before they are shown all acceptable files. This is achieved using a new FileItemDefinition::getSummarizedFileFilters() method that is available for you to use in your custom applications as well.

Previously, the file-browser dialog for all filesystem items (even extensible ones) only allowed you to select a single file at a time. Now extensible filesystem items allow you to choose multiple files and the qtItem subclass will add entries as needed to hold your list of selected files (if possible).

Improvements to Tabbing in Extensible Groups Items

Extensible group items are displayed in a Qt table widget instance with one row for each subgroup. Prior to SMTK 23.01, the table widget would not respond to tab key input (typically used for navigating between cells). This has been corrected for most mainstream cases including:

• double items
• integer items
• string items
• reference items (dropdown box format)

Tab-ordering also works with the discrete and expression versions of value items.

There are some cases that have not yet been implemented. The overall tab order might not be consistently preserved between the table widget and other items before and after it in the attribute editor. For optional items, the checkbox is not reliably included in the tab order. The tab behavior is also not currently defined for discrete items that include conditional children.

Custom item-view for ontology tagging

We’ve added a custom item-view (qtOntologyItem) for the Tag Individual operation mentioned above so users can add and remove ontology tags to markup nodes. It provides autocompletion as well as any descriptions the ontology provides, so that users can read guidance about whether an ontology tag applies to the node before they tag it.

Improvements for operation views

Sometimes custom items need access to the operation view which created them. This was not possible with smtk::extension::qtOperationView because internally it created a smtk::extension::qtInstancedView
which owned the item. So in SMTK 23.01 , we add the operation view to the instanced-view’s configuration-information type-container and add a method so items can fetch the configuration-information type-container from their parent view.

The new smtk::extension::qtOntologyItem above is an example of a qtItem intended specifically for operation views that needs to reset its state when its operation completes (and it needs to own the lock on the operation parameters in order to do this so it does not change the operation’s configuration while the operation running).

The operation view now provides a disableApplyAfterRun property which custom item views may set to indicate that re-running an operation with identical parameters is valid (or, in the case of qtOntologyItem, indicates the item cannot know when users have altered parameters due to deficiencies in Qt).

For more information, please see the release notes for 23.01 which can be found here and for 22.11 which can be found here.