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": [
"elasticity"
],
"role": "attributes"
}
],
"dependencies": [
2
],
"id": 3,
"strict-dependencies": true,
"style": [
"task3_view"
],
"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?