The example in the README has:

import (
    "fmt"
    glfw "github.com/go-gl/glfw3"
)

I always rename the glfw3 package to glfw so that it can be used like glfw.CreateWindow. I think the majority of people do the same, but I wouldn't be surprised if I find some people forgetting to do that and having incompatible code like glfw3.CreateWindow. It's a trivial difference, but still.

In an ideal world, I would like to see:

go-gl/glfw - latest version of glfw go-gl/gl/... - gl bindings (generated via glow)

go-gl/glow - only the glow binding generator itself

go-gl/glfw-legacy or go-gl-legacy/glfw - glfw 2.7 bindings.

That would be best for current users and new users who are just getting familiar with what is available under go-gl.

I don't think it's the best outcome to have legacy, outdated glfw 2.7 bindings using up the github.com/go-gl/glfw import path. Especially since this is Go, I see very little reason anyone would have to use older GLFW versions unless they have some legacy code they want to maintain; in all other cases you're better off with the latest stable GLFW version. This is not C++ where it's hard to update, just go get -u.

Of course, changing import paths is not easy, it has costs, and may not be possible. But I just wanted us to consider, can we do anything to improve the situation? What other people's thoughts?

Got rid of internal error callback. Never liked the way we solved it back then. It was not idiomatic and it was not mirroring the C API (worst of both worlds?). Now we have glfwGetError() function along with callback setting ability. It's still not idiomatic (only way to do it idiomatically is to return errors from all functions) but at least it mirrors the C API now. As always I'm open to suggestions. Any opinions?

I've also noticed that the 2 joystick functions we have were accepting the joystick IDs as arguments whereas we could have made it receivers. As our aim is to make the library as idiomatic as possible I've changed it. With 3.3 we have many more joystick functions so I think it looks better now. What do you think?

As a side note, I see no reason to implement the Vulkan functions. Thanks to Window.Handle() vulkan-go packages can access the GLFW window handle and create the necessary surface. So as is, it's ready for Vulkan.

README.md has the changelog as always, if you want to see the details.

Looks complete now according to this: http://www.glfw.org/docs/3.3/news.html Did I miss anything?

First, glfw3 builds as libglfw3 by default, so we link against that. Then, we have to link a few frameworks, to get rid of missing symbols.

glfw3 homebrew PR pending: https://github.com/mxcl/homebrew/pull/21620

FWIW, the glfw -> glfw3 move is probably valid for Linux too, but I can't test that right now, so not included.

I'm not quite sure what's the problem with the joystick configuration of my system, but the Go GLFW package panics with:

panic: PlatformError: Linux: Failed to watch for joystick connections in /dev/input: No space left on device
goroutine 16 [running]:
runtime.panic(0x501f80, 0xc20803e020)
    /home/christoph/go/src/pkg/runtime/panic.c:279 +0xf5
github.com/go-gl/glfw/v3.1/glfw.acceptError(0x7f769b90ae98, 0x1, 0x1, 0x0, 0x0)
    /home/christoph/gopath/src/github.com/go-gl/glfw/v3.1/glfw/error.go:164 +0x13d
github.com/go-gl/glfw/v3.1/glfw.Init(0x0, 0x0)
    /home/christoph/gopath/src/github.com/go-gl/glfw/v3.1/glfw/glfw.go:33 +0x70

The error itself is triggered at glfw/src/linux_joystick.c:_glfwInitJoysticks():213 which contains a comment in the following line saying: // Continue without device connection notifications. Therefore, I expect everything (except discovering new joysticks) to work. Unfortunately, the GLFW Go binding is way more strict and throws a panic in this case.

This PR adds support for the latest stable version of GLFW (3.3-stable from github).

I've addressed the issues of #219 :

• [x] idiomatic Go function (returns (*Thing, error))

• [x] Check for new methods implemented on GLFW side since #219 was made. (http://www.glfw.org/docs/3.3/news.html)

• [x] Check issue list for fixes postponed until 3.3 (except #235)

• [x] Re-base

• [ ] Make sure vulkan's working. I've ommited Vulkan specific things but we've had reports that they are necessary. Last time I've checked vulkan-go's glfw fork was not so different.

  (Not realy sure what to do here) Even if vulkan isn't very polished, important bug fixes, and other features are available.

I've renamed the v3.2 folder to v3.3 and then done the changes, this allows a 'cleaner' PR. I can also make this even cleaner with some filter (removes first commit) I'll add the v3.2 folder back after everything is green on you side.

This PR contains changes from the devel branch. That includes minor API changes that make the API easier to use and more idiomatic, as well as support for new features of GLFW 3.1. See changelog in README for a complete list of changes.

It is planned to be merged into master when GLFW 3.1 is released.

Closes #40. Closes #8. Closes #56. Closes #106.

Due to a bug in cgo we commented out https://github.com/go-gl/glfw/blob/master/v3.1/glfw/native_darwin.go (See Issue #82)

Unfortunately I don't have a mac, can we test if this is still an issue?

@slimsag was able to make the glfw3 Go package go-gettable by including GLFW sources inside. See https://github.com/azul3d/issues/issues/18#issuecomment-53160077.

If that really works, I think it's a great idea and we should consider doing that. Either as a separate package, or simply modify glfw3 to do it.

Any reasons not to do that?

Advantages:

• go-gettable Go package, much easier to use and install (especially for people trying to go get Go projects that import glfw3).

Disadvntages:

• More work for us, since we'll need to maintain and update a working version of GLFW C source.
• Less configurable? Unable to modify CMAKE parameters?
  • Are there any things that are worth modifying? I never changed anything besides the static build to make it compile, that's it.

Vulkan-go has its own fork of GLFW, but it's missing gamepad bindings which I really need. I've added some necessary functions from there to the original repository.

Follows up #198

Regarding the files wayland-pointer-constraints-unstable-v1-client-protocol.c, wayland-pointer-constraints-unstable-v1-client-protocol.h, wayland-relative-pointer-unstable-v1-client-protocol.c and wayland-relative-pointer-unstable-v1-client-protocol.h, they were generated using the wayland-scanner binary and the protocols defined on https://github.com/wayland-project/wayland-protocols.

$ wayland-scanner client-header < /usr/share/wayland-protocols/unstable/relative-pointer/relative-pointer-unstable-v1.xml > wayland-relative-pointer-unstable-v1-client-protocol.h
$ wayland-scanner client-header < /usr/share/wayland-protocols/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > wayland-pointer-constraints-unstable-v1-client-protocol.h
$ wayland-scanner code < /usr/share/wayland-protocols/unstable/relative-pointer/relative-pointer-unstable-v1.xml > wayland-relative-pointer-unstable-v1-client-protocol.c
$ wayland-scanner code < /usr/share/wayland-protocols/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > wayland-pointer-constraints-unstable-v1-client-protocol.c

I am not entirely sure we can add these files to the repo, but at least it builds correctly with no warning.

Installation fails:

(peter) ~ go get github.com/go-gl/glfw/v3.1/glfw
# github.com/go-gl/glfw/v3.1/glfw
/usr/bin/ld: cannot find -lXxf86vm
collect2: ld returned 1 exit status
(peter) ~ ll /usr/lib/libXxf86vm*
lrwxrwxrwx 1 root root    19 jun 10  2013 /usr/lib/libXxf86vm.so.1 -> libXxf86vm.so.1.0.0
-rw-r--r-- 1 root root 19808 mei 30  2013 /usr/lib/libXxf86vm.so.1.0.0

go version go1.4.2 linux/amd64 Debian 6.0

I am getting the following error while trying to run the simple demo code locally:

ld: unaligned pointer(s) for architecture arm64
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)

I am running Go v1.18.2 on an M1 Mac. I assume that the new chips are not yet fully supported. Is that correct?

I am getting these errors when building for Wayland. Opening the issue here in case there are issues on our end like last time.

# github.com/go-gl/glfw/v3.3/glfw
In file included from ../../vendor/github.com/go-gl/glfw/v3.3/glfw/c_glfw_lin.go:9:
../../vendor/github.com/go-gl/glfw/v3.3/glfw/glfw/src/wl_window.c: In function ‘createTmpfileCloexec’:
../../vendor/github.com/go-gl/glfw/v3.3/glfw/glfw/src/wl_window.c:115:10: warning: implicit declaration of function ‘mkostemp’; did you mean ‘mkstemp’? [-Wimplicit-function-declaration]
  115 |     fd = mkostemp(tmpname, O_CLOEXEC);
      |          ^~~~~~~~
      |          mkstemp
../../vendor/github.com/go-gl/glfw/v3.3/glfw/glfw/src/wl_window.c: In function ‘waitForData’:
../../vendor/github.com/go-gl/glfw/v3.3/glfw/glfw/src/wl_window.c:266:32: warning: implicit declaration of function ‘ppoll’; did you mean ‘poll’? [-Wimplicit-function-declaration]
  266 |             const int result = ppoll(fds, count, &ts, NULL);
      |                                ^~~~~
      |                                poll
../../vendor/github.com/go-gl/glfw/v3.3/glfw/glfw/src/wl_window.c: In function ‘_glfwPlatformGetClipboardString’:
../../vendor/github.com/go-gl/glfw/v3.3/glfw/glfw/src/wl_window.c:1866:11: warning: implicit declaration of function ‘pipe2’; did you mean ‘pipe’? [-Wimplicit-function-declaration]
 1866 |     ret = pipe2(fds, O_CLOEXEC);
      |           ^~~~~
      |           pipe

Hello good people,

My controller is not properly recognized on Linux when using the go GLFW package, and programs using it output this error :

GLFW: An uncaught error has occurred: InvalidValue: Invalid axis in gamepad mapping 03000000ad1b00002ef0000090040000 (Mad Catz Fightpad SFxT)
GLFW: Please report this bug in the Go package immediately.

In the program, it seems the buttons are recognized, but not the D-Pad.

The controller works fine while tested with jstest, and the D-Pad is recognized as an axis.

My other standard XBox 360 controllers do not have this problem.

Running on Ubuntu 21.10. using

github.com/go-gl/glfw/v3.3/glfw v0.0.0-20211213063430-748e38ca8aec // indirect

When using the go race detector (-race flag on build), the glfw.Init() function randomly hangs or crash.

Considering the following sample program :

package main

import (
	"runtime"

	"github.com/go-gl/glfw/v3.3/glfw"
)

func init() {
	runtime.LockOSThread()
}

func main() {
	err := glfw.Init()
	if err != nil {
		panic(err)
	}

	defer glfw.Terminate()
}

When running with -race it runs properly in 80% cases, but randomly either hangs forever or crash with this trace :

sample(42367,0x10189c580) malloc: Heap corruption detected, free list is damaged at 0x600001000240
*** Incorrect guard value: 0
daw(42367,0x10189c580) malloc: *** set a breakpoint in malloc_error_break to debug
SIGABRT: abort
PC=0x19cfb99b8 m=0 sigcode=0
signal arrived during cgo execution

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x100a38dcc, 0xc0000a5e98, 0xc0000a5e88)
	/usr/local/go/root/src/runtime/cgocall.go:154 +0x68 fp=0xc0000a5e60 sp=0xc0000a5e20 pc=0x10096b198
github.com/go-gl/glfw/v3.3/glfw._Cfunc_glfwInit(0xc000000000)
	_cgo_gotypes.go:1396 +0x58 fp=0xc0000a5e90 sp=0xc0000a5e60 pc=0x100a25a98
github.com/go-gl/glfw/v3.3/glfw.Init(0xc000048768, 0x10099a434)
	/usr/local/go/pkg/mod/github.com/go-gl/glfw/v3.3/[email protected]/glfw.go:36 +0x24 fp=0xc0000a5ef0 sp=0xc0000a5e90 pc=0x100a265e4
main.main()
	/path/to/repo/cmd/daw/main.go:19 +0x24 fp=0xc0000a5f70 sp=0xc0000a5ef0 pc=0x100a282f4
runtime.main()
	/usr/local/go/root/src/runtime/proc.go:225 +0x26c fp=0xc0000a5fd0 sp=0xc0000a5f70 pc=0x10099a46c
runtime.goexit()
	/usr/local/go/root/src/runtime/asm_arm64.s:1130 +0x4 fp=0xc0000a5fd0 sp=0xc0000a5fd0 pc=0x1009c9124

r0      0x0
r1      0x0
r2      0x0
r3      0x0
r4      0x0
r5      0x0
r6      0x1
r7      0x128ae0028
r8      0xd223c5dbf6f9927a
r9      0xd223c5daf77057fa
r10     0xcccccccccccccccd
r11     0xa
r12     0x0
r13     0x34
r14     0x1200000
r15     0x600002b01c80
r16     0x148
r17     0x1f77cb530
r18     0x0
r19     0x6
r20     0x10189c580
r21     0x103
r22     0x16f49ab80
r23     0x128ae0000
r24     0x0
r25     0x0
r26     0x16f49b95d
r27     0x10189c580
r28     0x4
r29     0x16f49aa90
lr      0x19cfeceb0
sp      0x16f49aa70
pc      0x19cfb99b8
fault   0x19cfb99b8
exit status 2

This does not reproduce without the -race flag.

Host : Mac M1 running Monterey Darwin hostname 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:41 PST 2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T6000 arm64

Tested using go 1.16 and 1.17.3.

https://github.com/fyne-io/fyne/issues/2373 details an error message.

This could be fyne specific, but it seems unlikely.

I Don't have access to their code, but it looks like vanilla fyne and go-gl/glfw 3.3

https://github.com/go-flutter-desktop/go-flutter/issues/186 mentions this https://github.com/go-flutter-desktop/go-flutter/issues/504 suggesting the remediation is to use a full machine. Makes sense as OSx crawls in a VM anyway. interestingly their issue 186 suggests it can be fixed, but the advice makes no sense to me, from altering go mod, to patching the local source with edits that seem non-explicit.