Skip to content

Comments

Fix retro evaluation and simplify retro interface#2248

Merged
veloce merged 2 commits intomainfrom
retro_fixes
Oct 5, 2025
Merged

Fix retro evaluation and simplify retro interface#2248
veloce merged 2 commits intomainfrom
retro_fixes

Conversation

@veloce
Copy link
Contributor

@veloce veloce commented Oct 5, 2025

No description provided.

.read(engineEvaluationPreferencesProvider)
.copyWith(engineSearchTime: kMaxEngineSearchTime)
: ref.read(engineEvaluationPreferencesProvider);
ref.read(engineEvaluationPreferencesProvider).copyWith(isEnabled: true, numEvalLines: 1);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These settings should not change based on some logic, as this will effectively kill and restart the engine.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, maybe we can add a warning comment about this somewhere in the code?

feedback: RetroFeedback.findMove,
mainlinePath: _root.mainlinePath,
pov: options.initialSide,
currentNode: RetroCurrentNode.fromNode(_root.view),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Avoid using root.view when possible.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, I think the missing conversion from view back to mutable node was the reason why I used views here

state.copyWith(feedback: RetroFeedback.evalMove, evalRequestedAt: DateTime.now()),
);
requestEval();
// Be sure to get enough depth to evaluate the move properly
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh that’s a much better solution of course, nice!


@override
bool get hideBestMoveArrow => analysisState.isSolving;
bool get hideBestMoveArrow => true;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, don't we want to show the arrows after the solution has been found, in case the user wants to analyse further?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is better to keep it separate from analysis, and then we don't want to use analysis settings. So I found it simpler to remove the lines and arrows for now.

await tester.pumpWidget(await makeTestApp(tester, moves: 'e4 e5'));

// Wait for retro to load
await tester.pumpAndSettle();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should always use pump instead of pumpOfSettle. The latter is normally only needed when you need to wait for an animation to finish.

expect(find.text('Try another move for white'), findsOneWidget);

await playMove(tester, 'd2', 'd4');
await tester.pumpAndSettle(const Duration(milliseconds: 500));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was causing the test to fail.

@veloce veloce merged commit f8d4d69 into main Oct 5, 2025
1 check passed
@veloce veloce deleted the retro_fixes branch October 5, 2025 11:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants