We are pleased to announce the release of SMTK 22.07 which includes the following improvements:

Expanding SMTK Attribute Resource’s Category Mechanism

The ability to assign category constraints to the various pieces of information stored within a SMTK Attribute Resource provides a way to “subset” the information based on parts of your simulation workflow. This makes it ideal when supporting multiple physics within a simulation or when doing task decomposition. Category information can be inherited both top-down (from Attributes down to their Items) and bottom-up (where Items can add additional category constraints to their parent Attribute or Item).

In 22.07, Category Modeling in SMTK Attribute Resources has been enhanced to now support specialization as well as generalization.
Previously, an Attribute or Item Definition’s local categories could only expand (make more general) the categories it was inheriting (or choose to ignore them all together). With this release, SMTK now supports specializing (or making the category constraint more restrictive).

Previously category inheritance was controlled by using the Definition’s setIsOkToInherit method which would either Or its local categories with those it was inheriting or Replace them. This method (as well as isOkToInherit method) has been deprecated. The new methods for setting and retrieving category inheritance are:

  • setCategoryInheritanceMode
  • categoryInheritanceMode

The values that categoryInheritanceMode can be set to are:

  • smtk::attribute::Categories::CombinationMode::Or
  • smtk::attribute::Categories::CombinationMode::And
  • smtk::attribute::Categories::CombinationMode::LocalOnly

Setting the mode to Or is the same as the previous setIsOkToInherit(true) – it will or the Definition’s local categories with those that it is inheriting. Setting the mode to And will now and the Definition’s local categories with those that it is inheriting. Setting the mode to LocalOnly will ignore the categories that the Definition is inheriting and is the same as the previous setIsOkToInherit(false).

Changing the Default Category Inheritance

Previously the default mode was isOkToInherit = true which now corresponds to smtk::attribute::Categories::CombinationMode::Or. Upon discussing the new combination support of And, it was decided that the new default will be smtk::attribute::Categories::CombinationMode::And, meaning that a Definition will be more specialized category-wise than it’s parent Definition.

Attribute items now have a “Reset to Default” context menu item

In SMTK 22.07, all the widgets used to input values for attribute items have a context menu item added called Reset to Default, which will change the value back to the default, if one is specified. If no default was specified, the menu entry is disabled. This means you will no longer need to remember what an Item’s default was in order to reset it back.

Int, Double, String, File, and DateTime items are all supported, including spin-box and multi-line views. Reference, Component, and Resource items don’t support default values.

As a result, qtInputItem no longer set themselves back to the default value when constructed – the default value is only applied by the ValueItem when created, or when the user chooses Reset to Default.

Showing the new Reset to Default mechanism in SMTK. Here the user is setting the End Item Item back to its default.

Changes to qtItem

Added the ability to hide an Item’s label

You can now indicate that the QLabel instance for an item should be hidden if its label is set to a (nonempty) blank string. Previously, template designers used a whitespace character to hide the label, however, a QFrame was still displayed and took up horizontal space. The new implementation essentially removes that unwanted space.

Changes to horizontally laid out Child Items

In SMTK 22.07, the Qt alignment was changed from vertical-center to top, for aesthetic reasons.

Changes to qtInputItem’s Layout Logic

In SMTK 22.07, the default behavior for a qtInputItem’s layout has been changed from being strictly horizontal to be the following:

  • For ordinary value items, the default layout is horizontal, but can be overridden by an ItemView <View Layout="Vertical">.
  • For extensible items, the layout is always vertical, and cannot be overridden by an ItemView.
  • For discrete value items with children items, the default layout is either:
    • horizontal – if each discrete value is assigned no child items or a
      single child item having a blank string for its label indicating that it’s label should not be displayed
    • vertical (otherwise)
    • The discrete item layout can be overridden by an item
      view, either <View Layout="Horizontal"> or
      <View Layout="Vertical">.
Example showing some of the new default layout conditions for qtInputItems.
Example of some of the new default layout conditions for qtItems that involve the underlying SMTK::attribute::ValueItem having active children.

Changes to SMTK’s ParaView Extensions

Separating Panels from Dock Widgets

Previously, several Panel classes derived directly from QDockWidget, so they could be docked by the user in whatever arrangement was desired.

To allow re-use and rearrangement, these Panel classes now derive from QWidget, and are placed inside a pqSMTKDock<T> which derives from QDockWidget. pqSMTKDock<T> has a template parameter to allow it to create the child Panel of the correct type. Panel classes must now implement void setTitle(QString title) to provide the pqSMTKDock<T> with the correct title, and use setWindowTitle() to provide the initial dock window title.

SMTK Resource Panel Changes

The :smtk:pqSMTKResourcePanel class now asks any :smtk:smtk::view::ApplicationConfiguration present for view configuration before using a default. This makes it simpler for applications to provide a custom phrase model, subphrase generator, or set of badges. Before this change, applications would have to wait for the panel to become ready and then reconfigure it.

Resource Panel Search Bar

A search bar has been added to the resource panel by default. Users may search for resource or components using a wildcard text-based search. The search bar is specified in the JSON config by adding "SearchBar": true to the Attributes group.

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

Leave a Reply