Analyze various user preferences related to node tree view

[herzbube]

This issue contains ideas for a number of user preferences which popped up during development of the node tree view feature. Before actually exposing one of these user preferences in the UI, consider whether it really brings value to the user or just contributes to feature creep.

• Show node numbers as overlay: Node numbers take up a fixed height at the top of the node tree view. Currently when the node tree view is scrolled the view content does not scroll "underneath" the node numbers. Users may wish to change this to behave similarly to how coordinates work in the board view. Experimental support for this already exists (cf. the NodeTreeViewModel property nodeNumberViewIsOverlay).
• Numbering style: The user can choose between "move numbers" and "node numbers". Selecting "move numbers" would likely need "align moves" to be enabled, because only then would all branches have the same move number in the same column. Selecting "move numbers" also has the potential to cause big gaps in the number strip if there are many nodes without moves.
• Numbering interval: The user can select to display only every n'th node number. Currently the numbering interval is 1, i.e. the node tree view attempts to display every node number. Experimental support for this already exists (cf. the NodeTreeViewModel property nodeNumberInterval).
  • How is this supposed to work with condensed move nodes? The current implementation already does not number all condensed move nodes.
  • When "condense move nodes" is enabled some move nodes are shown uncondensed if they are deemed to be "interesting" (e.g. branching nodes). Would it really make sense to not number these "interesting" nodes, in case the user selects an interval that causes them to be skipped?
• Only one symbol for setup: Currently the app shows many different symbols for setup nodes, depending on the type of setup that is in the node. The user may find this variety confusing, therefore a user preference to reduce variety might be useful.
• Node size: Currently the user has no influence on the size used to draw nodes. A user preference to let them choose from a certain bandwidth might be useful. Note that with the current sizes, condensed move nodes are already at the limit and cannot be possibly drawn smaller. If this user preference is considered, play around with the current system of 1/3 for condensed and 3/3 for uncondensed nodes.