I’m noticing that the select behavior defined via _findNearestPartTowards in DrawCommandHandler is not correctly handling grouped nodes.
In those cases I would expect to first navigate the group parent and arrow up/down to scroll through the children but the algorithm end up in the center first which is not intuitive.
Do you have a working solution or do I need to roll up my own here?
Thanks
Alain
Are you expecting to be able to go up and down the tree of groups, just as one can go up and down levels of trees of nodes and links when the arrowKeyBehavior is “tree”?
If so, I think you’ll need to implement that yourself. Perhaps you can copy and adapt the tree code.
Something along those lines (I added some numbered badges to show keyboard navigation within this diagram for example
Oh, perhaps I misunderstood your intent. Did you want the whole diagram to be in a total ordering, so that selecting the first node and hitting down arrow repeatedly will select each node in turn?
That too should be eminently implementable. But it is different from the navigation of node-link trees using arrow keys, which also supports explicitly collapsing and expanding subtrees.
Walter,
Looking for a solution that is as generic as possible, I went with a mode where navigation occurs within siblings as identified by their containingGroup. We always pre-select the topLeft part (dashed in my previous image). Here that happened to be the only “root” element. After that you press Enter to get into the first member of the group, the top left one. Within a group the standard DrawCommandHanlder findNearest algorithm is used. You press escape to return to the previous group level unless your at the root. That is quite intuitive and easy to navigate whatever the layout of the group subgraph.
Thanks
Alain
