# Discussion: how selection should interact with operations and attributes.
**URL:** https://discourse.kitware.com/t/discussion-how-selection-should-interact-with-operations-and-attributes/179
**Category:** Design
**Created:** [November 20, 2018, 11:47pm UTC](https://discourse.kitware.com/t/discussion-how-selection-should-interact-with-operations-and-attributes/179 "2018-11-20T23:47:23Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [November 20, 2018, 11:47pm UTC](https://discourse.kitware.com/t/discussion-how-selection-should-interact-with-operations-and-attributes/179/1 "2018-11-20T23:47:24Z")
@tj.corona @Bob_Obara We’ve had some discussion of how user selections should affect the operation and attribute panels (and vice-versa: how those panels should inform the selection).
As a first pass, [SMTK MR 1355](https://gitlab.kitware.com/cmb/smtk/merge_requests/1355) provides these controls:
1. They only appear when you mouse over the item so that the UI does not become cluttered.
2. The MR is not final. At a minimum, I want to also (a) highlight the item members in the 3-d view on mouseover; (b) add some of the buttons to the modal popup as well as where they are located now in the qtAttributeView; and © fix the logic that copies to/from the selection to handle items that only allow a single value. Once these are done, I think the selection interaction would be in a usable state.
However, since we also discussed some other approaches to dealing with the selection, I’m posting this topic. Please build the branch and give it a try with the _assign colors_ operation (which is all I have been testing it with).
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [November 21, 2018, 9:26am UTC](https://discourse.kitware.com/t/discussion-how-selection-should-interact-with-operations-and-attributes/179/2 "2018-11-21T09:26:42Z")
I’ve pushed some improvements that get highlighting of qtReferenceItem membership working:
This also shows a click on the “copy membership to selection” button at the end of the loop.
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [November 21, 2018, 8:49pm UTC](https://discourse.kitware.com/t/discussion-how-selection-should-interact-with-operations-and-attributes/179/3 "2018-11-21T20:49:21Z")
This is now merged into master, but we should still discuss how effective it is, what other controls should be provided, and what corner cases might need to be handled differently.
As far as corner cases go:
- TJ identified some astonishing behavior: selecting a volume with a tessellation in the resource panel, clicking “copy from selection” on _assign colors_’s associations item, and then immediately clicking “copy to selection” on the same item results in the volume being deselected. This happens because the second copy operation is a _filtered_ selection and the default filter excludes volumes. Should it be an unfiltered selection? Should the user be notified?
- There is also improper/astonishing behavior in cases when the selection and the item’s acceptable entries have a mismatch and “copy from selection” is clicked.
- We are discarding user changes that leave the item in an invalid state when the user shuts down the popup editor for qtReferenceItem. This is counter the human interface guideline that the user’s input should never be ignored (not accepting the input is different than completely ignoring it).
We also discussed having an “active selection link” button that would tie an item to the selection so that changes to the selection automatically update the item (to whatever extent is possible). That is not implemented and there is a question of how necessary it is.