Consistent user-faced fyne error reporting

[toaster]

Currently, we have a lot of fyne.LogError statements putting some kind of erroneous state out to stderr. #2976 introduced a Windows message box for a certain kind of error because most users and probably many developers would never see this.

I suggest, that we should implement fyne.LogError in a way that makes these errors visible to the user alongside the stderr output.

This would require a generic message box support for all OS:

• Windows can be taken from Use Windows MessageBox API for error when GLFW can't create a Window. #2976.
• MacOS probably has native support. If not, we might use at least the notifications.
• Linux has a lot of options. The most widely available might be xmessage. If a dialog is not available notify-send might be a usable fallback.
• Mobile is even more important because nobody looks at stderr there.
• In the browser we might use a JS alert?

[andydotxyz]

I'm not sure that I agree with this - most of the errors reported in LogError are not fatal or even relevant to the user.
In my thoughts a user being presented a dialog should normally (outside the GL booting) be controlled by the app.

Quite happy that graphics failures on all platforms could do what Cedric added in #2976, for other aspects I would be tempted to provide an error hook rather than showing every one to the user (especially as none of them are fatal).

[Jacalz]

I agree with @andydotxyz on this. I also want to add that, from what I have seen on Linux specifically, it seems like errors usually are printed to the console and are not directly displayed to the user.

[toaster]

Okay, so let’s leave the fyne.LogError as it is but provide some kind of fyne.ReportFatalError which presents the error to the user.
Would this be reasonable?

[Bluebugs]

This would be a nice improvement indeed.

For JS, Fyne app are not started if WebGL is not available and the splash screen display an error message directly. In a way, I think it is already done for the web backend to do what fyne.ReportFatalError could do.

[andydotxyz]

I wonder, would ReportFatalError always do the same thing?
If it relates to graphics setup clearly there is a good plan.
But if this is a public API and it is called once an app is up and running should it show a Fyne dialog instead?

I wonder if exporting it for general use and opening the above question is more trouble - how about it's internal and used only for graphics setup as has already been discussed?

[toaster]

Yeah, restricting it to internal use sounds reasonable.