Operation view

[dcthomp]

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:

  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?

[Bob_Obara]

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?

[dcthomp]

@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.

[dcthomp]

@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).

[Bob_Obara]

@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?

[dcthomp]

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.
  
  

[tj.corona]

Cool!