SMTK 23.04 Release Notes

See also SMTK 23.01 Release Notes for previous changes.

Changes to SMTK’s Task Subsystem

User Interface for Task-based Workflows (Preview)

SMTK now provides a ParaView plugin which adds a task panel similar to ParaView’s node editor. Each task is shown as a node in a graph and may be made active, marked complete (or incomplete), and manually placed by the user. Each task may have a collection of style keywords associated with it and the task manager holds settings for these keywords that affect the application state when matching tasks are made active.

In particular, SMTK’s attribute-editor panel can be directed to display any view held by attribute resource when a related smtk::task::FillOutAttributes task becomes active.

This functionality is a preview and still under development; you should expect changes to user-interface classes that may break backwards compatibility while this development takes place.

Operation Hint for Switching the Active Task

Any operation can now request the active task be switched by providing a hint on its result attribute. Use the smtk::operation::addActivateTaskHint() function to add the hint before your operation completes. Then, the pqSMTKOperationHintsBehavior object will observe when the operation has completed and process the hint and attempt to switch to the matching task. See smtk::project::Read for an example.

Task Management Changes

The task manager is no longer considered part of an application’s state. Instead of expecting an application’s Managers instance to hold a single task manager, each Project owns its own task manager.

As part of this change, the project read and write operations now include a serialization of the project’s task manager. This means that the task system JSON state is now properly serialized.

Another part of this change removes the smtk::task::json::jsonManager structure with its serialize() and deserialize() methods. You should replace calls to these methods with calls to to_json() and from_json(), respectively. Furthermore, you are responsible for pushing an instance of the task helper before these calls and popping the instance afterward. See the task tests for examples of this.

Finally, because smtk::common::Managers no longer contains an application-wide instance of a smtk::task::Manager, the signature for Task constructors is changed to additionally accept a parent task manager. The old signatures will generate compile- and run-time warnings. The constructors still accept a smtk::common::Managers since tasks may wish to monitor the application to determine their state.