Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show version mismatch warning in GUI #1503

Closed
hannobraun opened this issue Jan 12, 2023 · 0 comments · Fixed by #1554
Closed

Show version mismatch warning in GUI #1503

hannobraun opened this issue Jan 12, 2023 · 0 comments · Fixed by #1554
Labels
good first issue Good for newcomers type: feature New features and improvements to existing features

Comments

@hannobraun
Copy link
Owner

When loading a model, Fornjot checks the version of the fj crate that the model was compiled against, to compare it against the version of the Fornjot app. If there is a mismatch in the "package version" (for example, the version of the Fornjot app is 0.31.0, but the model uses fj version 0.30.0), this leads to an error that is displayed in the GUI.

On top of that, the app also checks the "full version", which includes the Git commit hash. This is useful, if either the app or the model use a development version instead of an official release. Since this is not necessarily a problem, and also not a case that most end users will have to deal with, this only results in a warning.

The problem is, this warning is only printed to stderr, which means the user might never see it. If that mismatch does cause a problem, this could be very confusing. Therefore, the warning should be shown in the GUI, maybe in addition to being printed to stderr.

The warning is printed in Model::evaluate, which is called by HostThread::process_model. HostThread already send events to the GUI via ModelEvent. To show this warning in the GUI, at least the following would have to be done:

  1. Add a mechanism to tell HostThread::process_model about the warning. Maybe by adding a warning: Option<String> to Evaluation, which is the return value of Model::evaluate.
  2. Add a variant to ModelEvent and send that in HostThread.
  3. Update the handling of ModelEvent accordingly.

I believe these steps should be relatively complete, which means the work that needs to be done is relatively limited in scope. Labeling https://github.com/hannobraun/Fornjot/labels/good%20first%20issue to reflect that.

@hannobraun hannobraun added type: feature New features and improvements to existing features good first issue Good for newcomers topic: host labels Jan 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers type: feature New features and improvements to existing features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant