l0k18
commented
3 years ago a possible solution is to use GLFW backend for linux to handle the window, this code is in pkg/gui would just require a build tag and platform_linux.go and platform.go with the core functions defining the platforms.
It may be driver related with different GL APIs or just the fact GLFW is a mature library to build a GL app on top of. Either way, it ultimately can cover windows and macos as well if there is reason to do so, or to make it switchable also, with one of those confirm things on opening a new instance.
There is a bug which causes the GUI thread to halt, and previous window loop code would detect it as a destroy event. It is some problem with the egl backend failing to create a context.
The bug is upstream and it can be worked around without an update by creating a failure recovery process to restart the window for this case, as it can be detected. It alternatively may be fixed as it's fairly simple and grotesque in its effect, but if it is fixed likely the widget code has to be revised to reflect other API changes as current when the patch appears.
Either path will require some hour or so of work to do something just to stay in the same place so for now it's a known bug that will be fixed when it becomes a priority and for now just to alert beta testers to beware of it, and it will retain the original buggy behaviour of shutting down completely.