Operation view

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::bridge::discrete::RemoveModel    <-- probably bad operator xml 
  smtk::bridge::discrete::SetProperty    <-- probably bad operator xml

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?

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?

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),

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

That would be good to provide in the default operator view for editing parameters.

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

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

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.