# The Curious Incident of the Operation Result In the Main Thread

**URL:** https://discourse.kitware.com/t/the-curious-incident-of-the-operation-result-in-the-main-thread/835
**Category:** Design
**Created:** [May 8, 2022, 6:11am UTC](https://discourse.kitware.com/t/the-curious-incident-of-the-operation-result-in-the-main-thread/835 "2022-05-08T06:11:08Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![dcthomp](https://discourse.kitware.com/user_avatar/discourse.kitware.com/dcthomp/32/10_2.png) [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [May 8, 2022, 6:11am UTC](https://discourse.kitware.com/t/the-curious-incident-of-the-operation-result-in-the-main-thread/835/1 "2022-05-08T06:11:08Z")

</div>

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,

1. The operation result itself does not have an obvious place to be destroyed because Qt-based applications use the `qtOperationLauncher` to 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).
2. 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 `qtReferenceItem`s. 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.