-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Fyne doesn't work on Windows 7 VM or remote server #410
Comments
The virtual machine would need to emulate a graphics card with OpenGL support and you would need the appropriate drivers installed. Virtualisation isn’t something we have looked at but there is no reason that version of Windows wouldn’t work and the file you compiled should work fine :) |
Hm. I downloaded the GLView program and it seems that OpenGL is installed, but the version is 1.1. It seems that's the latest version that MS bundled with the OS. It would probably be good to put this in the documentation somewhere. It appears there's a software-only Mesa renderer for Windows. I downloaded a prebuilt binary from https://github.com/pal1000/mesa-dist-win/releases, and hello world works now. Might also be a useful thing to put in the documentation? |
Thanks for the extra information. As far as I am aware the Windows operating system does not actually ship the OpenGL implementation but it sits within the graphics driver. We would like to avoid pointing people to a software mesa where possible as we want to provide good performance :) |
I'm using a Windows 7 VirtualBox VM that I downloaded from Microsoft's Modern.IE page: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ , so you can download it too if you want to test with it. :) It appears to have the generic 'VirtualBox Graphics Adapter'. After researching a little last night, I think you're right that Windows does not ship with OpenGL, and that it's up to the graphics driver to provide it. However, if you don't have a fancy graphics driver (eg, on a VM, or when using Remote Desktop), then you won't have OpenGL available to you, which means any Fyne app will just crash without much warning to a user. FWIW, my primary interest is having an easy to use cross-platform UI framework that I can use from golang that doesn't require me to jump through a bunch of hoops to use it. Because the sorts of things I'm looking to do are just 'normal' UI things (buttons, text, forms, etc), performance isn't really that important to me -- it's more important that I can hand a binary to an end user and it'll 'just work' without them having to do much work (which is one of the reasons I like golang for cross-platform development!). The basic fyne_demo command that comes with fyne performs without any noticeable stutter/etc problems using the software renderer. |
Thanks. Yes it seems you need 3.0 of VirtualBox to add OpenGL 2.0 which we currently require. There is a software driver in development also that is designed to enable the Go playground to provide previews and also a richer testing framework but it was never intended to work as a full driver due to concerns over performance. With a reasonable amount of work it is technically possible to extend this to provide a "fallback driver" but I don't know if this makes sense strategically? |
Just to confirm I also encounter the same problem as @virtuald using VirtualBox with a Windows 10 image. The Mesa software fixed the issue, but of course you don't want to have to troubleshoot this with regular users. I think it is possible to argue that virtual machines are unlikely to be used by end users, but remote desktop is a definite possibility. I personally think that a fallback driver, even with poor performance, is better than just seeing nothing happen. It doesn't sound like you think GLES support will fix the scenarios described in this issue on its own. Thank you for your hard work. |
An alternative to seeing nothing happen is to pop up a dialog box (using native message box stuff?) saying that OpenGL isn't available and "go to some link" to figure out what to do, which could tell them how to install mesa? Showing a panic on the console isn't a good fit for non-technical users, as they'll be more likely to just double click an app to run it, so they won't see the error message. |
I agree with the idea of better messaging when this happens. |
I also encounter the same problem as @danlester using VirtualBox 6.0 with a Windows 10 image.
|
Similar error here. On Windows 2012 on a Xen virtual machine over Remote Desktop Protocol (RDP), which is typically going to need ANGLE / GLES support DLL because the RDP means the windowing system will ignore the read of the remote hardware. However I thought that GLES support was in from fyne 1.2, so maybe I just need to know how to activate it?
|
If you want to force it to compile for GLES instead you can use I would have thought that you would need a DLL loaded to support either of these types of OpenGL though - let me know how it goes. |
yeah, I have the ANGLE and other DLLs in the directory... but it doesn't seem to notice and use them, so same crash as above. Is there code to load the DLLs that I can activate?
Jason
… On Jun 1, 2020, at 6:54 AM, Andy Williams ***@***.***> wrote:
If you want to force it to compile for GLES instead you can use
go build -tags gles . - we mostly auto-detect but this will override that.
I would have thought that you would need a DLL loaded to support either of these types of OpenGL though - let me know how it goes.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
I think I was getting OpenGL DLLs confused sorry. The drop-in replacement is Mesa3D I think - that supports being dropped into the current directory at runtime. |
VBox 6.1 , Virtual OS is win7. By default the 3D acceleration is disabled, enabling it allowed to run the fyne_demo app correctly.
thanks for Lucor. |
Fyne looks awesome, and works great out of the box on my mac. I tried to cross-compile for Windows from my mac, and that generates an exe. So far, so good:
Unfortunately, when I run it on my Windows VM (a Windows 7 VirtualBox VM downloaded from Modern.IE), it gives me the following error that others seem to have.
I was hoping that this would 'just work' on a bare Windows installation, but that doesn't seem to be the case. Is this configuration supported? What am I missing?
The text was updated successfully, but these errors were encountered: