[nodes] ExpressionTextField improvements

[Alxiice]

Description

• Moved the evaluation to python
• Correct text field bindings so that the slider/reset etc works well

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.41%. Comparing base (aabe589) to head (5c650c9).
⚠️ Report is 5 commits behind head on develop.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #2892   +/-   ##
========================================
  Coverage    79.41%   79.41%           
========================================
  Files           51       51           
  Lines         6987     6987           
========================================
  Hits          5549     5549           
  Misses        1438     1438           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[cbentejac]

Besides the clean-up comments, I have a few notes:

• mathEvaluator.js (in meshroom/ui/qml/Utils) can be removed from the project since it is (unless I missed something) now fully replaced, and references to it in the qmldir can also be removed.
• getEvalExpression is called when the value is validated, when the focus on the text field is lost or when the expression has just been validated. For example, setting the value "10*2" then pressing "Enter" then moving to another attribute will trigger the call 3 times: once with "10*2", immediately after with "20" and then again with "20". The beginning and end call are necessary, but is it avoidable to retrigger the evaluation as soon as it has ended?

Otherwise, I do not have any functional notes, everything is clean, the code is actually simpler than it was in the initial version, so bar the tiny comments, it's ready to be merged.

[Alxiice]

Besides the clean-up comments, I have a few notes:

* `mathEvaluator.js` (in meshroom/ui/qml/Utils) can be removed from the project since it is (unless I missed something) now fully replaced, and references to it in the `qmldir` can also be removed.

* `getEvalExpression` is called when the value is validated, when the focus on the text field is lost or when the expression has just been validated. For example, setting the value "`10*2`" then pressing "Enter" then moving to another attribute will trigger the call 3 times: once with "`10*2`", immediately after with "20" and then again with "20". The beginning and end call are necessary, but is it avoidable to retrigger the evaluation as soon as it has ended?

Otherwise, I do not have any functional notes, everything is clean, the code is actually simpler than it was in the initial version, so bar the tiny comments, it's ready to be merged.

I removed one occurence by checking if the text has changed since last evaluation, I'm not sure if it's better but let me know what you think!

[cbentejac]

There's a regression that has probably been introduced with #2836: when editing a text field, not pressing "Enter" and clicking somewhere else (thus losing focus), the value of the field is lost (the attribute is then set with value "0"). This wasn't the case in Meshroom 2025.1.0: when losing the focus, the value was still validated and applied to the attribute.

The Component.onCreated slot should also be removed, as it performs an evaluation right after the one triggered by onTextChanged while there could not possibly have been a value change.

[Alxiice]

There's a regression that has probably been introduced with #2836: when editing a text field, not pressing "Enter" and clicking somewhere else (thus losing focus), the value of the field is lost (the attribute is then set with value "0"). This wasn't the case in Meshroom 2025.1.0: when losing the focus, the value was still validated and applied to the attribute.

The Component.onCreated slot should also be removed, as it performs an evaluation right after the one triggered by onTextChanged while there could not possibly have been a value change.

The best way I found for now was to call accepted on Component.onDestroyed, it seems to fix the problem