Well, maybe we can just figure out the VB settings or version of Windows I need.

What version of Windows is the image running? What are your Virtual Box settings? In particular, what's the VB Display -> Graphics Controller? Inside Windows, what's the display adapter? And anything else that seems appropriate.

As mentioned above, I'm running VBoxVGA with 2D & 3D acceleration enabled. The VMSVGA (which I've since learned is a VMWare driver? or emulation of their driver?) does run Gio, but has some drawbacks (like it won't resize the VM window to arbitrary sizes). The VBoxSVGA driver doesn't run Gio.

I won't have access to the Fedora 30 I tried Windows on, sorry. I can tell you that I didn't change anything - I imported the image from the link above and accepted the defaults VirtualBox presented.

I'm trying to get VirtualBox to run now; hopefully it will exhibit the same error that you see.

VirtualBox unfortunately didn't make any difference for me: Gio programs ran fine.

It does, thanks!

Re: the specific error: If I understand correctly (which I might not), we get back EGL_BAD_CONFIG. I don't really understand the GL config thing. Does that mean we asked for a particular config, or set of configs, and the GL library said basically nothing I have matched what you're asking for?

Basically, yes.

And if so ... is there any chance we can ask for something else, that would work?

Absolutely. That's my motivation behind the two branches I earlier, and for running Windows in Gnome Boxes. I'm trying to get VirtualBox to run now; hopefully it will exhibit the same error that you see.

On Tue, Aug 13, 2019 at 4:34 PM ~theclapp outgoing@sr.ht wrote:

I guess I was suggesting that, yeah, but when you put it that way, never mind. :) That seems sufficient.

It does seem a little weird that it gets far enough to pop up a window and then dies. (At least I think that's what it did; I'm away from that computer right now.) But we'll probably just have to live with that.

It is a little weird and earlier versions of app.NewWindow did return an error value. The were several reasons I dropped it in favor of DestroyEvent:

• It's simpler.
• I had to add DestroyEvent anyway, to propagate errors that happen after NewWindow (e.g. running outof GPU memory). If a program needs to handle DestroyEvent, we might as well shove initialization errors in as well.
• NewWindow should only fail in extraordinary cases, at least when Gio is mature enough to cover all GPU backends (Vulkan, D3D, Metal). On platforms such as iOS and newer Androids this property is already true.
• It's not unreasonable to imagine a software fallback if no GPU backend is available at all.

I hope that gave some perspective on that particular design choice.

On Tue, Aug 13, 2019 at 3:07 PM ~theclapp outgoing@sr.ht wrote:

Yeah, the virtual machine substrate / hardware are important. I'm running Virtual Box. So I think it comes down to hardware / driver support. So I don't think Gio is doing anything wrong or bad.

That said, it would be nice if Gio could detect the lack of support for what it needs, so devs like me and users like my friend on Slack know that it'll just never work. Did you try the Virtual Box image, or something else? I know it's a lot of trouble, but maybe try to find one that doesn't work and then you can troubleshoot the capability checking Gio needs to do?

I'll definitely keep digging for a configuration that doesn't work. But given a configuration that doesn't work and will never work (accelerated) are you suggesting Gio add more functionality than the DestroyEvent with Err != nil notification?

FWIW, I downloaded a Windows 10 image from https://developer.microsoft.com/da-dk/windows/downloads/virtual-machines and ran it in Gnome Boxes on my Fedora 30 Silverblue.

The first run took a while (converting the virtual image?), but to my surprise, installing Go and running

$ go build gioui.org/apps/gophers

just worked. The ANGLE dlls had to be in the current directory, of course.

On Mon, Aug 12, 2019 at 3:22 PM ~theclapp outgoing@sr.ht wrote:

This was in the Gophers showandtell channel, btw. See

https://gophers.slack.com/archives/C02A3DRK6/p1565482138087000.

(I also created a #gioui channel

(https://gophers.slack.com/archives/CM87SNCGM/p1565385539002600). I

know you're not a fan of Slack (and I mentioned this in the channel),

but I'm fine with it. :)

My personal opinion is largely irrelevant here. I'm grateful for all mentions, so thank you! :D

Did your friend's Windows run go-life if he puts the ANGLE dlls in the dll search path (or current directory)? If so, this issue should be renamed to something about virtual Windows.

According to this, error code 0x3000 is EGL_SUCCESS, so 🤷‍♂️.

I suspect the immediate issue is that eglChooseConfig succeeds but return no configs. I pushed https://git.sr.ht/~eliasnaur/gio/commit/560591955538a49a352d36e59780928be3889e73 to fix that. However, even if I'm right, the program will still fail, but with a different error message.

I can't reproduce the error on my Windows 10, so I can't debug the issue. However, not finding a config at all is a pretty basic error.

One reason could be that your Windows 10 VM doesn't support hardware accelerated rendering.

Another reason could be Gio calling eglChooseConfig with attributes that doesn't sit well with ANGLE.

For the second theory, I've pushed two branches with a shot-in-the-dark attempts. Please try to run go-life after running

$ go get gioui.org/ui@debug-issue-22

and after

$ go get gioui.org/ui@debug-issue-22-2

Thanks.

~eliasnaur could you write a short doc with the steps one would have to follow to implement X11 support? Perhaps then someone with enough interest could step in and start contributing patches.

Good idea.

The platform specific packages in Gio are ui/app and ui/app/internal/gl.

I don't think you need anything X11 specific in the gl package.

The app package takes care of creating a native window, binding an OpenGL ES context and handling input. I suggest you use the Wayland port as a starting point.

Dynamic switching between the Wayland and X11 backends would be nice, but as a first goal I suggest defining a build tag, say x11, that switches from Wayland to X11 at build time.

So the first step is adding

// +build !x11

to every wayland-specific Go and C files. You'll have to modify the go:generate directives in oswayland.go to add the x11 condition to the generated Wayland C files (waylandxdgshell.c, waylandxdgdecoration.c, waylandtext_input.c).

What I usually do at this point of adding a new port is to make minimal changes and empty types, functions, methods etc. to make a Gio program build and run. Use the hello or gophers example for that.

Then, I work through the necessary steps for creating a Window and binding a context. The goal is to get the drawing to show up in a window. Note that Gio programs won't draw before Window.setStage(StateRunning) has been called.

For input I wire up event handling to route mouse and keyboard input back to the Gio program. My experience with X11 tells that this is where most of the issues will be. Things like key code translation, scroll wheel etc. were fiddly when I did the X11 port for LWJGL.

Finally, polish: lifecycle for minimizing/maxizing, setting the window title and size and so on.

Hope that helps. I'll gladly expand on any issues you run into.

• elias