# Operation view
**URL:** https://discourse.kitware.com/t/operation-view/94
**Category:** Design
**Created:** [April 23, 2018, 6:57pm UTC](https://discourse.kitware.com/t/operation-view/94 "2018-04-23T18:57:57Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [April 23, 2018, 6:57pm UTC](https://discourse.kitware.com/t/operation-view/94/1 "2018-04-23T18:57:58Z")
All, but especially @Bob_Obara:
I’ve got selections in modelbuilder generating a list of available operations and have come up with a few questions on the operation panel. Here’s what I’m planning:
In real life, the list of operations that work with a given selection is not as appetizing as the prototype above because many unrelated or uninteresting operations are valid and interspersed with the useful operations. For example, with a polygonal face selected I see:
```nohighlight
smtk::model::AddImage
smtk::model::AssignColors
smtk::model::CreateInstances
smtk::model::ExportModelJSON
smtk::model::GroupAuxiliaryGeometry
smtk::model::SetProperty
smtk::model::TerrainExtraction
smtk::bridge::discrete::RemoveModel <-- probably bad operator xml
smtk::bridge::discrete::SetProperty <-- probably bad operator xml
smtk::bridge::polygon::CleanGeometry
smtk::bridge::polygon::CreateVertices
smtk::bridge::polygon::CreateEdge
smtk::bridge::polygon::CreateEdgeFromPoints
smtk::bridge::polygon::CreateFaces
smtk::bridge::polygon::CreateFacesFromEdges
smtk::bridge::polygon::Delete
smtk::bridge::polygon::DemoteVertex
smtk::bridge::polygon::ForceCreateFace
smtk::bridge::polygon::SplitEdge
smtk::bridge::polygon::TweakEdge
smtk::bridge::polygon::ExtractContours
smtk::bridge::mesh::EulerCharacteristicRatio
smtk::bridge::mesh::Export
```
I’ve added a workflow directory to SMTK and a new class that will downselect and relabel operations. However, that class must still be initialized and updated. With a manual set of preferred operations, that leads to a view in modelbuilder like this:
That still leaves questions:
- How should this workflow class that filters+orders operations be initialized for now? In my branch, I’m just reading JSON from a fixed path, which is not an answer. It seems like several pieces of information related to the workflow need a place to live:
- the set of plugins that modelbuilder should load by default;
- the workflow task graph (which does not exist yet), which will definitely want to change the preferred order of operations if not also the list of “approved” operations; and
- affinities between operations and workflow tasks (so that not only the first operation listed, but the order of all viable operations can depend on the selection).
- When it comes to using an existing operation in multiple ways (e.g., turning polygon-session’s _create edge_ into both _create river_ and _create road_), we’ve discussed simply subclassing the operation. But what about relabeling an operation’s items? Overriding an item’s description (brief or detailed)? Hiding items? Marking items as advanced? All of these things are currently stored in the attribute system but arguably belong in “view” instead so that we don’t have to maintain multiple copies of the operator’s XML/JSON specification.
- What if you’re editing an operation’s parameters and change the application selection? Should the operation edits be abandoned (this seems wrong and anyway, edits that don’t invalidate the operator will be preserved in the attribute collection for the operator).
- How should we deal with “operator stay” functionality — where a user wants to re-run an operation multiple times, with or without parameter edits?
---
### Author:  [@Bob\_Obara](https://discourse.kitware.com/u/Bob_Obara)
#### Post date: [April 24, 2018, 2:28pm UTC](https://discourse.kitware.com/t/operation-view/94/2 "2018-04-24T14:28:24Z")
I think this looks good but I think there are a few issues:
- Some operators are not able to run without specifying parameters so how do we indicate to the user which operators are runnable and which are not? We could use color (not great for color blind folk) or use an icon.
- Assuming that operators remember the parameters used when they were last run, then “click here to run with defaults” if possible should say: “click here to run with last executed parameters or defaults is it has not been previously executed”
- Along those lines, should there be an icon that resets an operator back to its default values?
Concerning the figure:
Face 9 is selected but the operation list seems to be including operations that are not applicable (like split edge) - am I missing something or is the figure wrong?
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [April 24, 2018, 3:31pm UTC](https://discourse.kitware.com/t/operation-view/94/3 "2018-04-24T15:31:04Z")
> [@Bob\_Obara](#):
>
> … there are a few issues:
>
> - Some operators are not able to run without specifying parameters so how do we indicate to the user which operators are runnable and which are not? We could use color (not great for color blind folk) or use an icon.
I assumed that the “\>” icon would be normal, inverted, or greyed out depending on whether an operation could
- run in either mode (with defaults or with non-default settings)
- run only with non-default settings (not all defaults are good)
- run only as is (no user-adjustable settings),
respectively.
> [@Bob\_Obara](#):
>
> - Assuming that operators remember the parameters used when they were last run, then “click here to run with defaults” if possible should say: “click here to run with last executed parameters or defaults is it has not been previously executed”
Some functionality along those lines would be nice. If we could provide it without the clutter of another icon or “secret” modifier keys, that would be nicer. For instance, we might have “current defaults” and “factory defaults” that you can set when editing parameters. The icon would only run with “current defaults” but you can reset to factory defaults in the parameter editor (operator view).
> [@Bob\_Obara](#):
>
> - Along those lines, should there be an icon that resets an operator back to its default values?
That would be good to provide in the default operator view for editing parameters.
> [@Bob\_Obara](#):
>
> Concerning the figure:
>
> Face 9 is selected but the operation list seems to be including operations that are not applicable (like split edge) - am I missing something or is the figure wrong?
It looks like a bug because the operator XML specifies edge association.
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [April 24, 2018, 4:09pm UTC](https://discourse.kitware.com/t/operation-view/94/4 "2018-04-24T16:09:36Z")
> [@dcthomp](#):
>
> It looks like a bug because the operator XML specifies edge association.
Fixed. Some operator XML associations were using the _MembershipMask_ XML tag rather than _Accepts_ entries, which should still have been supported but wasn’t. Also, those operations should not be using _MembershipMask_ because _Accepts_ allows you to restrict operations to particular resource types (e.g., the polygon split edge op should only accept polygon edges, not all model edges).
---
### Author:  [@Bob\_Obara](https://discourse.kitware.com/u/Bob_Obara)
#### Post date: [April 24, 2018, 5:03pm UTC](https://discourse.kitware.com/t/operation-view/94/5 "2018-04-24T17:03:36Z")
> [@dcthomp](#):
>
> I would say that you load in the workflow file (which would create the new project) - similar to an attribute template. Then the workflow file would be copied into the project directory and get loaded when the project is loaded. Without the workflow the user would see all of the native operators provided by the sessions that get loaded in.
>
> the set of plugins that modelbuilder should load by default;
> the workflow task graph (which does not exist yet), which will definitely want to change the preferred order of operations if not also the list of “approved” operations; and
> affinities between operations and workflow tasks (so that not only the first operation listed, but the order of all viable operations can depend on the selection).
>
> When it comes to using an existing operation in multiple ways (e.g., turning polygon-session’s create edge into both create river and create road), we’ve discussed simply subclassing the operation. But what about relabeling an operation’s items? Overriding an item’s description (brief or detailed)? Hiding items? Marking items as advanced? All of these things are currently stored in the attribute system but arguably belong in “view” instead so that we don’t have to maintain multiple copies of the operator’s XML/JSON specification.
> What if you’re editing an operation’s parameters and change the application selection? Should the operation edits be abandoned (this seems wrong and anyway, edits that don’t invalidate the operator will be preserved in the attribute collection for the operator).
> How should we deal with “operator stay” functionality — where a user wants to re-run an operation multiple times, with or without parameter edits?
- How should this workflow class that filters+orders operations be initialized for now? In my branch, I’m just reading JSON from a fixed path, which is not an answer. It seems like several pieces of information related to the workflow need a place to live:
- relabeling operator parameters would also need to be specified - maybe providing a map?
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [April 26, 2018, 3:03pm UTC](https://discourse.kitware.com/t/operation-view/94/6 "2018-04-26T15:03:45Z")
Here’s a movie showing some variations on the theme:
- As @Bob_Obara suggested, there’s an option to “unfilter” the list of operations. It’s still only the subset whitelisted by the workflow.
- I’m not hiding the list of available operations in this version, just using a splitter. The best would probably be to put everything in a vertical scrolling container and then scroll so the parameter editor is at the top of the frame when you double-click an operation.
- Custom views are now registered properly with the UI manager.
- Operations aren’t being run yet… the old operation view simply emits a signal to request the operator be run. The new one will actually queue it.
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [April 26, 2018, 6:05pm UTC](https://discourse.kitware.com/t/operation-view/94/7 "2018-04-26T18:05:46Z")
Cool!