Trees should expand height-wise upon hover

USE CASE: WHAT DO YOU WANT TO DO?

Be able to select & view any tree node by hovering height-wise(/tree-wise).

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

Open a cdt file.
Hover over a tree
See all internal nodes instead of a single pixel line with multiple branches seemingly stemming from it

CURRENT BEHAVIOR

In the context of a column tree... When a tree has many nodes which are very close together (height-wise), the horizontal portions of branches stemming from internal nodes are often drawn at the same vertical pixel level. It's possible to select any internal node by hovering horizontally (i.e. across the data axis), but not when hovering tree-height-wise (i.e. vertically over the column trees). Also, you cannot see where many of the internal nodes are. See attached screen recording.

EXPECTED BEHAVIOR

In the context of a column tree... When you hover over a tree, nodes on a single path should be forced to not be drawn at the same pixel level. Tree nodes should be (vertically) spaced so that every node can be hovered individually by moving the mouse vertically. The tree should revert to a compact (and accurate) representation when the mouse hovers off.

This means that the vertical dimension of the tree needs to expand on hover. Expanding that dimension of the tree means that the vertical dimension of the tree needs to grow larger that the size of the portion of the split-pane it is in. This could be handled by either adding a scrollbar or auto-scrolling the tree vertically in the same way that labels auto-scroll with hover horizontally. Since auto-scrolling upon hover could be jumpy, scrolling with a scrollbar would be preferable, though that means that hover over the scrollbar or splitpane divider should also expand the tree vertical height.

alternate suggestion: Possibly, a simpler fix would be to allow the user the ability to resize the area that the entire splitpane divider takes up. This is what issue ~~#36~~ calls for.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

The shortest pixel height of a tree can be calculated by making the shortest distance between 2 nodes on the same path equate to 1 pixel's length (or 1.5 pixels to be safe).

The size of the tree should be expanded off the edge furthest from where the mouse is when it enters the pane.

Possible alternate enhancements: 1. anti-alias the lines to better indicate where nodes are when the mouse is not hovered over the trees.

It is suggested to modify the suggested changes as needed to ensure the user experience is not jarring/disorienting. E.g. if the height of the tree changes drastically upon hover, it could be very disorienting. It is suggested that a scenario to envision is that the user may have his/her eye on a node they want to click on and that upon entering the tree area, if that node jumps off the screen, they might not intuitively know how to get to it. Thus, it might be necessary to modify this suggested change to mitigate that issue. Once possibility would be to include a preference setting or other feature to turn the "expanding tree feature" off.

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

TRView
RowTreeView
ColumnTreeView
Treepainter
TreeDrawer

LEVEL OF EFFORT - developers only

major

COMMENTS

Since our app is called TreeView, we should probably trick-out the tree navigation features such as how this issue suggests.

Here is a screen recording of the problem this issue describes. As you can see, moving the cursor vertically 1 pixel goes from 2 branches selected to 5 branches selected. Each pixel traversed vertically up should actually only select 1 more branch each time from 2 to 3 to 4 to 5. However, since 4 branches seemingly stem from a single parent node, it goes from 2 directly to 5. Note, the 4 internal nodes could be selected by hovering horizontally, but that is not shown here.

https://bitbucket.org/TreeView3Dev/treeview3/downloads/treehoverdifficult.mov

Note that one possible behavior was considered and rejected: the capability of maximizing the tree portion of the splitpane divider automatically to accommodate a taller tree (as much as needed). I rejected this idea because the user may want to see more of the labels while hovering over the tree.

Comments (10)