Subtree red highlight can differ from red bold leaf highlight

Issue #388 resolved
Robert Leach created an issue

USE CASE: WHAT DO YOU WANT TO DO?

Accurately select a subtree that is highlighted in red.

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

  1. Open small_133x133.cdt
  2. Hover over a 2-node subtree whose left or right neighboring leaf is a part of a subtree that is larger than the 3 leaves combined (see red (2-node subtree) & yellow (neighboring subtree) highlighted regions of column tree in attached image).
  3. Very slowly drag left or right until the next leaf's branch is bold red and the subtree its parent is the root of is not all red (see attached image)
  4. Left-Click

CURRENT BEHAVIOR

The neighboring leaf's branch from it's parent to the leaf will appear in bold red. The rest of that parent's subtree is not highlighted in red. The click will select that whole subtree. The previously hovered two-node subtree remains highlighted in red.

red_tree_highlight_bug.png

EXPECTED BEHAVIOR

The whole subtree defined by the parent of the bold red leaf should be highlighted in red. The resulting yellow selection should be the same subtree that is highlighted in red. If the previously red 2-node subtree is not a part of the neighboring leaf's parent's subtree, it should no longer nbe highlighted in red. The bold leaf and the redsubtree should basically always coincide.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

Since this bug happens both to the left and right of a 2-node subtree, I suspect this does not have to do with the calculation of the hovered matrix position being off by +/- 1. This is demonstrated by the fact that if you move the cursor 1 pixel up or down, the red highlight will be corrected. So this is probably either a failure in logic or a delayed update of the cursor position.

FILES AFFECTED (where the changes will be implemented) - developers only

unknown

LEVEL OF EFFORT - developers only

minor

COMMENTS

Comments (5)

  1. Robert Leach reporter

    This commit resolves issue 388. The hover index that was set inside the mouseMoved method had to be set before the hoveredNode was set because hoveredNode was using the current hoverIndex to determine the currently hoveredNode, thus it was getting out of synch.

    → <<cset e885826df4c3>>

  2. Robert Leach reporter

    This commit resolves issue 388. The hover index that was set inside the mouseMoved method had to be set before the hoveredNode was set because hoveredNode was using the current hoverIndex to determine the currently hoveredNode, thus it was getting out of synch.

    → <<cset e885826df4c3>>

  3. Log in to comment