Adding Task Galleries to Projects

Currently, the user interface support for Task Workflows allows the user to create and follow predefined workflows. Kitware is actively looking to extend this to allow a user to build their own workflows from a gallery of pre-configured Tasks and Task Worklets.

Representing the Task Gallery (in JSON)

Since Tasks are currently represented in JSON, SMTK will use JSON for representing the Task Gallery as well.

The following shows the JSON representation of a Project’s Task Workflow:

  "task_manager": {
    "adaptors": [
        "from": 1,
        "id": 1,
        "to": 3,
        "type": "smtk::task::adaptor::ResourceAndRole"
    "styles": {
      "operation_view": {
        "operation-panel": {
          "focus-task-operation": true
      "task3_view": {
        "attribute-panel": {
          "attribute-editor": "Elasticity"
    "tasks": [
        "auto-configure": true,
        "id": 1,
        "resources": [
            "max": 1,
            "role": "attributes",
            "type": "smtk::attribute::Resource"
        "title": "Assign Attribute Resource",
        "type": "smtk::task::GatherResources"
        "id": 2,
        "title": "Plain Task",
        "type": "smtk::task::Task"
        "attribute-sets": [
            "instances": [
            "role": "attributes"
        "dependencies": [
        "id": 3,
        "strict-dependencies": true,
        "style": [
        "title": "Edit Attributes",
        "type": "smtk::task::FillOutAttributes"

We propose to reuse this format for the Task Gallery with a couple additions:

"task_gallery": {
  "worklets" : [
      "name" : "Worklet 1",
      "operation" : "name of operation used to instantiate worklet",
      "schema" : "name of the schema of the worklet",
      "version" : "version of the schema",
      "UUID" : "uuid of the worklet",
      "adaptors": [...],
      "styles": {...}, <--- Not in the initial implementation
      "tasks": [...]

In this formant, the gallery contains an array of worklets. Each worklet is composed of the name of the worklet, the name of a SMTK operation used to instantiate the worklet, and the structure of the worklet itself. Optionally, the worklet can have a version and schema associated with it. This would be used in the case of updating the worklet to a new version. UUID is the identifier used to reference the worklet by a task that is instantiated by the worklet.

Default Values if not specified

  • UUID : none - not specifying the ID indicates that an UUID should be given to the worklet when deserialized.
  • version : 0
  • schema : empty string

Changes to Tasks

We would add the following properties to a task in order to allow for updating to a new version.

  • schema : “name of the schema of the task”,
  • version : “version of the task”,
  • workletId : “uuid of the worklet”

A Question on Styles

In theory, a Worklet could define a set of “private styles” that could be overridden by the consuming Project. For the initial implementation, I would hold off on doing this but could be added if the need arises. In that case, styles that a Worklet references would assumed to be defined within the Project.

Where to store the Task Gallery?

Inside the Project

The simplest place to store the gallery would be in the Project itself.

  • Pros
    • Guaranteed to not get separated from the rest of the Project.
  • Cons
    • Technically, the gallery can exist prior to the creation of the Project since it can be considered part of the Project’s schema and would be “inserted” into the Project during Project Creation.

Outside of the Project

In this case, the gallery could be stored in a different directory such as a sub-directory of a Project-Plugin. In this approach the Project file may instead store the file location of the gallery (galleries) which set at Project Creation.

  • Pros
    • Can easily exist in file format prior to the creation of the Project and could even be “inserted” into an existing Project after construction.
  • Cons
    • Could complicate sending a Project to another user if they don’t have access to the same version of the plugin.

Other Questions

  • Should a Gallery (or Worklet) be versioned?
    • This could be required if a Worklet can be upgraded to a newer version.
  • Should a Gallery (or Worklet) be associated with a Schema?

@Bob_Obara This looks like a good start.

  1. Task-gallery JSON. I don’t think we should support a styles section inside gallery entries:
    a. What would it mean? The only thing it could mean (as far as I can tell) is that there are some styles that only apply to instances of this gallery entry. But that can be achieved by adding style names specific to gallery entries to the global task-manager styles.
    b. Forcing another cascade of styles could be expensive.
  2. Task-gallery Location. I would start by putting the task gallery inside the project because, as you point out, it is the simplest thing to do. Until projects have the notion of a template or schema, it will be hard to support the task gallery there. And we definitely do not want an application-global task gallery (someone might drop things from one project type into another by accident).

@justin.2.wilson @Aaron @rohith @johnt - FYI

Task-gallery style entries

After talking with @Bob_Obara , I agree that there is a use case for including styles inside task-gallery entries, but think those styles should be harmonized with the task-manager’s styles as the gallery is imported into the task manager (i.e., at the time the gallery is ingested, not at the time gallery entries are instantiated into tasks). We discussed two use cases in regard to harmonization:

  • Task gallery distributed with the project. As a user drops a task-gallery instance into a project, the gallery entry has style that should override the project’s defaults.
  • Task galleries transferred between users. Projects should override an imported gallery-entry’s style on conflict (presumably because users do not want to import preferences from other users but choose to keep their own).

We have not settled on how to resolve this.

Tasks becoming components

We are also moving forward with making smtk::task::Task inherit smtk::resource::Component. This is for a variety of reasons, but the driving issue is that deserializing a task-gallery entry (where arcs in a gallery entry reference tasks by human-legible, reusable integers) should produce tasks with unique IDs. These IDs will be needed to retain information about which gallery entry produced which tasks.

I’ve missed some of the design discussions on this topic, so I have some beginner/layman questions.

  • I’ll first note that many of my questions might be address by adding a strawman example, perhaps for 1 or 2 tasks in the workflow example at the beginning of this topic. I think this would be very helpful.

  • In terms of definitions, is “worklet” a new software component being added to smtk, or is it more simply a placeholder/name to invoke some new task manager function?

  • When a gallery item is selected to be instantiated, I presume the worklet software runs the operation specified in its configuration? Will that operation’s UI be displayed in a modal dialog or something like that?

  • Do we expect to need different operations to instantiate different gallery items?

  • Are we using an operation in anticipation of converting tasks to smtk components? (Otherwise it’s not obvious to me why an operation is needed.)

  • What information is contained in the worklet schema? (something different than the operation’s specification, I presume)

A worklet will be a new component (i.e., likely inherit smtk::resource::Component along with smtk::task::Task after cmb/smtk!2874). You can think of it as a bolus of task JSON (adaptors, tasks, and eventually style).

Yes. The operation will probably be displayed in the parameter-editor panel.

Yes. The operation SMTK will provide will just deserialize the worklet’s JSON bolus into a project’s task manager. But if a worklet also wishes to create a new resource and configure the deserialized tasks to use it, that is the responsibility of whoever creates the worklet.

Yes. I’ve rebased and almost got cmb/smtk!2874 ready to merge.

So far, just the name of the operation class to instantiate and run. The operation will be expected to associate to a worklet (assuming worklets are components imported into the target project) and take no other parameters.