aevaCMB currently exhibits some counter-intuitive behavior due to a quirk of SMTK: visual representations of primitive-selections (individual points/cells, not SMTK components) sometimes persist in the 3-D view even after the SMTK selection changes.
The reason for this is that some operations create a primitive-selection that is intended to be ephemeral (i.e., the selection does not appear in the resource browser and the smtk::view::Selection – rather than the resource – holds the shared pointer intended to keep the primitive-selection alive) rather than persistent. For these operations, the operation result’s created and modified items also contain a reference to the primitive-selection. And the operation result is kept alive by the SMTK tool parameter-editor dock-widget. Indeed, changing the selection and then closing the tool parameter-editor tab for the operation causes a re-render that removes the primitive-selection (because both the operation and its result are destroyed when the tab is closed).
The solution would seem to be: destroy the operation result sooner. However,
- The operation result itself does not have an obvious place to be destroyed because Qt-based applications use the
qtOperationLauncherto force operation observers to be invoked on the main thread at some indeterminate period of time later (whenever the event loop gets around to it). - The tool parameter-editor widget does not currently but should display the results of any operation. If we insist the results object be destroyed, then we prevent this feature.
Proposed solutions
Alternative 1: Provide user control
Show results explicitly and provide the user a way to access the selection. For instance, we might provide operation views with a way to display the result attribute that would include the created, modified, and perhaps even expunged components in their own qtReferenceItems. Because qtReferenceItem provides highlighting and selection control, users can put the operation’s output back into the selection or remove it from the result themselves.
Alternative 2: Kill kill kill!
We could have the qtOperationLauncher destroy the operation result once the signal has been delivered on the main thread by registering a low-priority observer that adds a second Qt::QueuedConnection event to the event-loop which deletes the result. But it is unclear whether this could still lead to issues since other observers may also queue Qt events and be registered with low priority.