This can be a problem, as stated in a checklist:
Bug: If one has label 1 selected and then hides/show label 2 then it will look to the user as if label 2 is now selected. However, it seems that label 1 is still selected and all operations still work on label 1. This can be quite confusing.
Description
Revisions and Commits
Restricted Differential Revision |
Status | Assigned | Task | ||
---|---|---|---|---|
Resolved | floca | T29077 [Segmentation] Showing / hiding labels using the labelsetwidget selects them | ||
Resolved | floca | T29206 [SEG] Implement a Qt model for LabelSets for MVC patterns | ||
Resolved | floca | T29475 QmitkMultiLabelInspector: Should right click change selection? |
Event Timeline
I couldn't find a good solution to this. Some points that are problematic:
- opening the context-menu using right-click will select the item / row
- disabling specific columns / cells is not possible with a table widget
- using a table view and a customized model would allow this, but
- then it wouldn't be possible to click a button inside this cell
- using simple checkboxes instead of the icon-buttons could work but then the previously highlighted selection is lost (and no new selection is highlighted)
- using a table view and a customized model would allow this, but
I have a possible solution for this:
- looking at the mentioned issue in the task description the problem seems to be that clicking on the show / hide button (or the color button or the locked button) will highlight the corresponding item / row but it does not change the active label
- this led to confusion because the highlighted label is not the active label anymore
-> change the active label selection also in that case
With this approach everything would be consistent but the user would (accidentally) switch the active label every time, if he or she changes the "label settings", such as color, visibility etc.
To overcome this we could think about another mechanism to "jump to the center of a label" and use the double-click to activate a label. However, that leads to the problem that a highlighted item / row (single-click, right-click etc.) does not represent the active-state anymore.
There seems to be a problem with the connected messages. I wanted to exploit the ActiveLabelEvent being sent to change the label for the currently active label (https://phabricator.mitk.org/source/mitk/browse/develop/Plugins/org.mitk.gui.qt.segmentation/src/internal/QmitkSegmentationView.cpp$664). It seems as if this only connects the events of the currently active label set and new label sets (e.g. on a new layer) are not connected. I need to look deeper into this to see if I made an error while removing the redundancy (and moving this event-connection to the classic segmentation view) or if it was erroneous from the beginning.
I added a fix in D625, which uses the discussed approach of printing the active label above the labelsetwidget.
The problem with this approach is the same as the one I already presented:
Started dicussion about it. Current discussion result: We should go for a new model view based implementation instead of try to fix the current boiler plate code.
Have to discuss design of the model view pattern in detail in the next MITK meeting.