Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Fixed
-
Labels:None
Description
In IGB, if you select multiple items and then CONTROL-SHIFT-CLICK one of the selected items, the item you clicked is supposed to be de-selected and the other items currently selected remain selected.
However, this feature appears to be broken. Now, if you want to deselect an item, you have to click on its parent, which is possible only if the item's parent glyph is visible.
In other words, if the item is a single span feature (covering the "parent") then it is impossible to de-select it w/o also deselecting everything else.
In IGB 6.7, it was possible to deselect any item using SHIFT-CONTROL-click. Can we revert back to the IGB 6.7 behavior?
I propose that:
If user clicks an item while pressing SHIFT-CONTROL, the item and its parent should be deselected. If the item is not currently selected, nothing should happen.
Attachments
1. |
Test edge matching on variety of data type |
|
Closed | Unassigned |
Activity
Fixed in r14269.
Tested drag selected as well as shift+click selected - they deselect fine. Tested "solid" reads as well as gapped reads, also work fine.
Fixed for v7.0 on r14334.
The bug is back it seems. If you DRAG select reads, you can NOT deselect them by SHIFT + CONTROL + click.
Also, If you use SHIFT + CONTROL + click on a read not already selected, it will select... so it is toggling selected and deselected.
Fixed in r14359.
Please test all possible way of selection. Also test that edge matching is working.
-dragging works from all directions
-SHIFT-click adds items
-SHIFT+CONTROL+click will deselect items from either selection method
-SHIFT+CONTROL+click will ALSO select unselected items!
-edge-match works appropriately; color change works; show/hide works
Actually - here is the bug I see. Load up a bam file. Select by dragging over a few reads which do NOT have gaps. Us SHIFT + click to add a few more reads. Now use CONTROL + SHIFT + click to deselect the added reads - they deselect fine. Try deselecting reads from the original 'drag' and these will NOT deselect. This is NOT a problem for reads which contain a gap, if you deselect on the gap. So it is the 'drag selected, ungapped' reads that are at issue.
On a reference gene track, EST, etc. the select and deselct works fine. This seems to affect only the .bam reads