automatically expand the current children node

[HaonRekcef]

Automatically expand the children of the currentNode, closes #2494

The perf impact is negligible, as only the current children get looped.

Screencast_20260514_173011.webm

I implemented for studies and analysis, I do not see a reason to do it for broadcasts.

[veloce]

I'm ok in principle for the feature and implementation.

But see comment: it should only be applied if not fast seeking the game.

Also since the asked change would complexity a bit the logic I'd like to have 2 simples tests for this: one that shows it does not expand when fast seeking, and one that shows it does for simple move jump.

Thanks!

[veloce]

Recomputing rootView is expensive. Are you sure about the performance implications? Seems like it would impact the fast forward/rewind feature.

IMO this should be disabled if fast forward/rewind and only apply to a single jump.

[HaonRekcef]

I found two cases where nodes are automatically collapsed:

mobile/lib/src/model/common/node.dart

Line 558 in 249010c

isCollapsed: frame.nesting > 2 || hideVariations && childIdx > 0,

and

mobile/lib/src/model/analysis/server_analysis_service.dart

Line 214 in 249010c

isCollapsed: children.length > 1,

So I am wondering if we need the fast-forward logic:
As for the first case the collapsed nodes are not direct children of the mainline and fast-forwarding a variation with a lot of sub-variations seems very rare.

It might be a problem for the second case, as direct children of the mainline nodes are collapsed. But this is actually very niche: people requesting a server analysis and then long-pressing through it. A game that is reopened would not have them collapsed because it would use the logic from the first case. Also a normal game would be very light to compute the rootView for, as it barely has variations.

So the one possible problem I can see is for huge studies. After requesting a computer analysis, those lines are collapsed and then the user fast-navigates through the moves, rootView would need to be recomputed every time.

The only other possibility where this problem appears is when a user manually collapses a lot of variations in a huge study, but tbh this also seems very unlikely.

I think these cases are too rare to deserve their own handling logic in the code. What do you think, @veloce?