Keyboard tree navigation

Summary: Keyboard navigation is a complicated issue and each client has different behavior. What should the expected behavior of Sabaki be?

This was going to be a feature request until I did some research. It is related to #174.

Consider the sgf and game tree below. I checked keyboard navigation on Sabaki, cgoban3, OGS, eidogo and gopanda2. Pretend all trees are oriented the same way. For eidogo and gopanda all keyboard navigation can only move on one branch. We’ll label the four columns 1, 2, 3, and 4 and then give an absolute position for rows 1, 2, 3, 4, 5 and 6 (i.e. the root of the tree is at col:1 row:1, the bottom right corner is col:4 row:6).

Results: A: At col: 2 row: 6 -> press left sabaki - col: 3 row: 4 cgoban - nothing ogs - col: 1 row: 6

B: At col: 1 row: 6 -> press right sabaki - col: 2 row: 3 cgoban - nothing ogs - col: 2 row: 6

C: At col: 2 row: 3 -> press left sabaki - col: 1 row: 3 cgoban - highlight other branch starting at col: 2 row: 3 ogs - col: 1 row: 3

D: at col: 1 row: 2 -press right sabaki - nothing cgoban - highlight other branch starting at col: 1 row: 2 ogs - nothing

I think Sabaki shines here with B (go to the root of the next branch over) but that same behavior is pretty problematic visually in A. I really like the cgoban behavior in D but overall the only way to get from one place to another is to navigate through the root. The OGS behavior is the most similar to Sabaki and it always allows for moving left or right to any point that is on that level. How should keyboard navigation work in Sabaki?

(;GM[1]FF[4]CA[UTF-8]AP[Sabaki:0.30.3]KM[6.5]SZ[19] ;B[dd] (;W[de] ;B[df] ;W[dg] ;B[dh] )(;W[ee] (;B[ef] ;W[eg] ;B[eh] )(;B[ff] (;W[fg] ;B[fh] )(;W[gg] ;B[gh] ))))

[yishn]

WYSIWYG and invertible left/right keys coming in v0.43.0.

[Walther]

I would personally think about this from the average end-user usefulness perspective:

1. Implement OGS style movement (i.e. remap left and right to go to the corresponding node on whatever branch is visually there)

“What you see is what you get” -> potentially highest usefulness for most casual users

1. Implement KGS style movement (i.e. remap left and right to do nothing unless at a branch point)

Logical, but allows less movement -> potentially slightly less useful

If you don’t have the game tree open, you can’t predict where you will end up.

If you don’t have a game tree open and you press a key shortcut intended semantically for “switch branch” command (or similar), one would have to have the game tree memorized for this to be useful - certainly possible, but probably not the average use case. And on the other hand, if your use case is “I wonder if there are variations available here”, the more useful option than to try clicking switch-branch key from each node, is to simply open the game tree visually and immediately see where the possible variations are located.