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

Use Windows MessageBox API for error when GLFW can't create a Window. #2976

Merged
merged 1 commit into from May 16, 2022

Conversation

Bluebugs
Copy link
Contributor

Description:

This use Windows native API to create a MessageBox that display an error for all problem related to the GL driver. Specifically useful when the OpenGL driver is not available.

Fixes #2689

Checklist:

  • Tests included.
  • Lint and formatter run with no errors.
  • Tests all pass.

@Bluebugs Bluebugs requested a review from andydotxyz May 14, 2022 15:29
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.006%) to 61.533% when pulling 9f671e6 on feature/graceful-failure-windows-gl into 61b61b4 on develop.

@toaster
Copy link
Member

toaster commented May 15, 2022

This PR let me think about error reporting in general and I’ve the following questions:

  1. Shouldn’t GL errors always be fatal because a Fyne app without graphics output is fairly useless?
  2. Shouldn’t we present errors on all platforms consistently (this does not only apply to GL errors), i.e. with some kind of native message box if the user is unlikely to see the log?

Copy link
Member

@andydotxyz andydotxyz left a comment

Choose a reason for hiding this comment

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

Looks good to me thanks

@Bluebugs Bluebugs merged commit 381f1f4 into develop May 16, 2022
@Bluebugs Bluebugs deleted the feature/graceful-failure-windows-gl branch May 16, 2022 15:08
@Bluebugs
Copy link
Contributor Author

1. Shouldn’t GL errors always be fatal because a Fyne app without graphics output is fairly useless?

In the code path that trigger this MessageBox, it is indeed fatal and the application will quit after the MessageBox is acknowledge by the user (driver.go:initFailed#149 and driver.go:initFailed#152). I would think if there is other path that should abort, they should call initFailed too.

2. Shouldn’t we present errors on all platforms consistently (this does not only apply to GL errors), i.e. with some kind of native message box if the user is unlikely to see the log?

That would be nice. It might be possible on macOS, but it won't on Linux/BSD which doesn't have a native message box API (Arguably on those OS, people are more used to the command line, so maybe less of an issue). Maybe opening another issue to look into how to do things on macOS would make sense?

@toaster
Copy link
Member

toaster commented May 17, 2022

That would be nice. It might be possible on macOS, but it won't on Linux/BSD which doesn't have a native message box API (Arguably on those OS, people are more used to the command line, so maybe less of an issue). Maybe opening another issue to look into how to do things on macOS would make sense?

I think, we could even try to make this work on Linux. At least we might try notify-send or xmessage or alike in addition to the command line error.

I’ll open an issue.

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.

None yet

4 participants