Go bindings for GLFW 3


GLFW 3.3 for Go Build Status GoDoc


  • GLFW C library source is included and built automatically as part of the Go package. But you need to make sure you have dependencies of GLFW:
    • On macOS, you need Xcode or Command Line Tools for Xcode (xcode-select --install) for required headers and libraries.
    • On Ubuntu/Debian-like Linux distributions, you need libgl1-mesa-dev and xorg-dev packages.
    • On CentOS/Fedora-like Linux distributions, you need libX11-devel libXcursor-devel libXrandr-devel libXinerama-devel mesa-libGL-devel libXi-devel libXxf86vm-devel packages.
    • See here for full details.
  • Go 1.4+ is required on Windows (otherwise you must use MinGW v4.8.1 exactly, see Go issue 8811).
go get -u github.com/go-gl/glfw/v3.3/glfw


If your target system only provides an OpenGL ES implementation (true for some ARM boards), you need to link against that implementation. You do this by defining the appropriate build tags, e.g.

go get -u -tags=gles2 github.com/go-gl/glfw/v3.3/glfw

Supported tags are gles1, gles2, gles3 and vulkan. Note that required packages might differ from those listed above; consult your hardware's documentation.


package main

import (

func init() {
	// This is needed to arrange that main() runs on main thread.
	// See documentation for functions that are only allowed to be called from the main thread.

func main() {
	err := glfw.Init()
	if err != nil {
	defer glfw.Terminate()

	window, err := glfw.CreateWindow(640, 480, "Testing", nil, nil)
	if err != nil {


	for !window.ShouldClose() {
		// Do OpenGL stuff.


GLFW 3.3 Specific Changes

  • Joystick functions now uses receivers instead of passing the joystick ID as argument.
  • Vulkan methods are intentionally not implemented. Window.Handle can be used to create a Vulkan surface via the this package.
  • Renamed Window.GLFWWindow to Window.Handle
  • Added function Window.SetAttrib.
  • Added function Window.RequestAttention.
  • Added function Window.GetContentScale.
  • Added function Window.GetOpacity.
  • Added function Window.SetOpacity.
  • Added function Window.SetMaximizeCallback.
  • Added function Window.SetContentScaleCallback.
  • Added function Monitor.GetWorkarea.
  • Added function Monitor.GetContentScale.
  • Added function Monitor.SetUserPointer.
  • Added function Monitor.GetUserPointer.
  • Added function InitHint.
  • Added function RawMouseMotionSupported
  • Added function GetKeyScancode.
  • Added function WindowHintString.
  • Added function GetClipboardString.
  • Added function SetClipboardString.
  • Added function Joystick.GetHats.
  • Added function Joystick.IsGamepad.
  • Added function Joystick.GetGUID.
  • Added function Joystick.GetGamepadName.
  • Added function Joystick.GetGamepadState.
  • Added function Joystick.SetUserPointer.
  • Added function Joystick.GetUserPointer.
  • Added function UpdateGamepadMappings.
  • Added function SetX11SelectionString.
  • Added function GetX11SelectionString.
  • Added gamepad button IDs.
  • Added gamepad axis IDs.
  • Added joystick hat state IDs.
  • Added ModifierKey ModCapsLock.
  • Added ModifierKey ModNumLock
  • Added InputMode LockKeyMods.
  • Added InputMode RawMouseMotion.
  • Added hint Hovered.
  • Added hint CenterCursor.
  • Added hint TransparentFramebuffer.
  • Added hint FocusOnShow.
  • Added hint ScaleToMonitor.
  • Added hint JoystickHatButtons.
  • Added hint CocoaChdirResources.
  • Added hint CocoaMenubar.
  • Added hint TransparentFramebuffer.
  • Added hint value OSMesaContextAPI.
  • Added hint value CocoaGraphicsSwitching.
  • Added hint value CocoaRetinaFramebuffer.
  • Added string hint value CocoaFrameNAME.
  • Added string hint value X11ClassName.
  • Added string hint value X11InstanceName.
  • MonitorEvent renamed to PeripheralEvent for reuse with joystick events.
  • Joystick.GetButtons Returns []Action instead of []byte.
  • SetMonitorCallback Returns MonitorCallback.
  • Focus No longer returns an error.
  • Iconify No longer returns an error.
  • Maximize No longer returns an error.
  • Restore No longer returns an error.
  • GetClipboardString No longer returns an error.

GLFW 3.2 Specfic Changes

  • Easy go get installation. GLFW source code is now included in-repo and compiled in so you don't have to build GLFW on your own and distribute shared libraries. The revision of GLFW C library used is listed in GLFW_C_REVISION.txt file.
  • The error callback is now set internally. Functions return an error with corresponding code and description (do a type assertion to glfw3.Error for accessing the variables) if the error is recoverable. If not a panic will occur.
  • Added function Window.SetSizeLimits.
  • Added function Window.SetAspectRatio.
  • Added function Window.SetMonitor.
  • Added function Window.Maximize.
  • Added function Window.SetIcon.
  • Added function Window.Focus.
  • Added function GetKeyName.
  • Added function VulkanSupported.
  • Added function GetTimerValue.
  • Added function GetTimerFrequency.
  • Added function WaitEventsTimeout.
  • Added function SetJoystickCallback.
  • Added window hint Maximized.
  • Added hint NoAPI.
  • Added hint NativeContextAPI.
  • Added hint EGLContextAPI.

GLFW 3.1 Specfic Changes

  • Added type Cursor.
  • Added function Window.SetDropCallback.
  • Added function Window.SetCharModsCallback.
  • Added function PostEmptyEvent.
  • Added function CreateCursor.
  • Added function CreateStandardCursor.
  • Added function Cursor.Destroy.
  • Added function Window.SetCursor.
  • Added function Window.GetFrameSize.
  • Added window hint Floating.
  • Added window hint AutoIconify.
  • Added window hint ContextReleaseBehavior.
  • Added window hint DoubleBuffer.
  • Added hint value AnyReleaseBehavior.
  • Added hint value ReleaseBehaviorFlush.
  • Added hint value ReleaseBehaviorNone.
  • Added hint value DontCare.

API changes

  • Window.Iconify Returns an error.
  • Window.Restore Returns an error.
  • Init Returns an error instead of bool.
  • GetJoystickAxes No longer returns an error.
  • GetJoystickButtons No longer returns an error.
  • GetJoystickName No longer returns an error.
  • GetMonitors No longer returns an error.
  • GetPrimaryMonitor No longer returns an error.
  • Monitor.GetGammaRamp No longer returns an error.
  • Monitor.GetVideoMode No longer returns an error.
  • Monitor.GetVideoModes No longer returns an error.
  • GetCurrentContext No longer returns an error.
  • Window.SetCharCallback Accepts rune instead of uint.
  • Added type Error.
  • Removed SetErrorCallback.
  • Removed error code NotInitialized.
  • Removed error code NoCurrentContext.
  • Removed error code InvalidEnum.
  • Removed error code InvalidValue.
  • Removed error code OutOfMemory.
  • Removed error code PlatformError.
  • Removed KeyBracket.
  • Renamed Window.SetCharacterCallback to Window.SetCharCallback.
  • Renamed Window.GetCursorPosition to GetCursorPos.
  • Renamed Window.SetCursorPosition to SetCursorPos.
  • Renamed CursorPositionCallback to CursorPosCallback.
  • Renamed Window.SetCursorPositionCallback to SetCursorPosCallback.
  • Renamed VideoMode to VidMode.
  • Renamed Monitor.GetPosition to Monitor.GetPos.
  • Renamed Window.GetPosition to Window.GetPos.
  • Renamed Window.SetPosition to Window.SetPos.
  • Renamed Window.GetAttribute to Window.GetAttrib.
  • Renamed Window.SetPositionCallback to Window.SetPosCallback.
  • Renamed PositionCallback to PosCallback.
  • Ranamed Cursor to CursorMode.
  • Renamed StickyKeys to StickyKeysMode.
  • Renamed StickyMouseButtons to StickyMouseButtonsMode.
  • Renamed ApiUnavailable to APIUnavailable.
  • Renamed ClientApi to ClientAPI.
  • Renamed OpenglForwardCompatible to OpenGLForwardCompatible.
  • Renamed OpenglDebugContext to OpenGLDebugContext.
  • Renamed OpenglProfile to OpenGLProfile.
  • Renamed SrgbCapable to SRGBCapable.
  • Renamed OpenglApi to OpenGLAPI.
  • Renamed OpenglEsApi to OpenGLESAPI.
  • Renamed OpenglAnyProfile to OpenGLAnyProfile.
  • Renamed OpenglCoreProfile to OpenGLCoreProfile.
  • Renamed OpenglCompatProfile to OpenGLCompatProfile.
  • Renamed KeyKp... to KeyKP....
  • Package name meta-issue, can we rename package to glfw?

    Package name meta-issue, can we rename package to glfw?

    The example in the README has:

    import (
        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?

    opened by dmitshur 80
  • 3.3 beta - don't merge yet

    3.3 beta - don't merge yet

    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?

    opened by tapir 29
  • Adjusted link flags for Mac OS X

    Adjusted link flags for Mac OS X

    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.

    opened by lloeki 28
  • Can not initialize GLFW without joystick support

    Can not initialize GLFW without joystick support

    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.

    opened by tux21b 27
  • GLFW 3.3

    GLFW 3.3

    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.

    opened by pchampio 25
  • API changes and support for GLFW 3.1 features.

    API changes and support for GLFW 3.1 features.

    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.

    opened by dmitshur 25
  • Native Darwin Support

    Native Darwin Support

    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?

    opened by tapir 23
  • Consider making glfw3 Go package go-gettable by vendoring GLFW inside?

    Consider making glfw3 Go package go-gettable by vendoring GLFW inside?

    @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?


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


    • 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.
    enhancement question thinking 
    opened by dmitshur 22
  • Added missing functions for compatibility with Vulkan

    Added missing functions for compatibility with Vulkan

    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.

    opened by zergon321 21
  • Fix build for wayland

    Fix build for wayland

    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.

    opened by thomasruiz 19
  • cannot find -lXxf86vm

    cannot find -lXxf86vm

    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

    opened by pebbe 19
  • unaligned pointer(s) for architecture arm64

    unaligned pointer(s) for architecture arm64

    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?

    opened by preslavrachev 6
  • v3.3/glfw: Warnings when building using -tags wayland

    v3.3/glfw: Warnings when building using -tags wayland

    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
    glfw-3.3 wayland 
    opened by Jacalz 1
  • Axis not recognized with Street Fighter

    Axis not recognized with Street Fighter "Mad Catz" Fightpad.

    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
    opened by ssj17vegeta 0
  • Crash during Init() when using race detector

    Crash during Init() when using race detector

    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 (
    func init() {
    func main() {
    	err := glfw.Init()
    	if err != nil {
    	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
    	_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
    	/path/to/repo/cmd/daw/main.go:19 +0x24 fp=0xc0000a5f70 sp=0xc0000a5ef0 pc=0x100a282f4
    	/usr/local/go/root/src/runtime/proc.go:225 +0x26c fp=0xc0000a5fd0 sp=0xc0000a5f70 pc=0x10099a46c
    	/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.

    opened by arcln 0
  • X-POST from Fyne NSGL failed to find suitable pixel format

    X-POST from Fyne NSGL failed to find suitable pixel format

    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.

    opened by Lewiscowles1986 0
OpenGL with Golang
OpenGL with Golang
Compute shader in GO (using go-gl/glfw)

shadr (compute shader using go-gl/glfw) structure main.go contains intialisation

null 1 Jan 20, 2022
Basic Go bindings for FLTK

Go FLTK This is a simple go wrapper for FLTK2, which I did to support my Go version of Ober (based on Acme), Gober. It's very small and should be fair

Bill Burdick 31 Mar 12, 2022
qt5 bindings for go

#go-qt5 ##Before you start This is a fork of visualfc's qt4 bindings, and several critical bugs are inherited along the way. Until these bugs are fixe

Utkan Güngördü 421 Jan 1, 2023
Tcl/Tk Go bindings

Tcl/Tk Go bindings. VERSION NOTICE Recently Tcl/Tk 8.6 were released. I use them as a default, if you still have Tcl/Tk 8.5 use `go get -tags tcl85

null 141 Nov 21, 2022
Go bindings for GTK3

gotk3 The gotk3 project provides Go bindings for GTK 3 and dependent projects. Each component is given its own subdirectory, which is used as the impo

gotk3 1.9k Jan 6, 2023
Golang bindings of Sciter: the Embeddable HTML/CSS/script engine for modern UI development

Go bindings for Sciter Check this page for other language bindings (Delphi / D / Go / .NET / Python / Rust). Attention The ownership of project is tra

Terra Informatica Software, Inc 2.5k Dec 23, 2022
:traffic_light: Go bindings for libappindicator3 C library

go-appindicator Go bindings for libappindicator3 C library. Libappindicator is a library to allow applications to export a menu into the Unity Menu ba

Dawid Dziurla 20 Jun 19, 2022
gobbi is a set of generated Go bindings for gtk et al.

gobbi gobject bindings gobbi is a set of generated Go bindings for gobject based libraries. There are bindings, with varying degrees of completeness,

Mike D Pilsbury 29 May 6, 2022
This project provides Go bindings for nuklear.h — a small ANSI C GUI library.

Nuklear Package nk provides Go bindings for nuklear.h — a small ANSI C gui library. See github.com/vurtun/nuklear. All the binding code has automatica

null 1.5k Jan 1, 2023
A GTK4 bindings generator for Go.

gotk4 A GTK4 bindings generator for Go. Progress tracker: https://github.com/diamondburned/gotk4/issues/2 All generated packages are in pkg/. The gene

null 266 Jan 6, 2023
Golang bindings for XCGUI, Windows GUI library, DirectUI design idea.

XCGUI 项目文档 帮助文档 程序示例 介绍 English | 简体中文 DirectUI设计思想: 在窗口内没有子窗口,界面元素都是逻辑上的区域(无HWND句柄,安全,灵活), 所有UI元素都是自主开发(不受系统限制), 更加灵活的实现各种程序界面,满足不同用户的需求.

twgh 224 Dec 22, 2022
Go bindings for divideon/xvc

go-xvc [WIP] Go bindings for divideon/xvc Requirements requires xvc install on your system $ git clone https://github.com/divideon/xvc.git $ cd xvc $

Yusuke Hata 0 Feb 7, 2022
Go bindings for GLFW 3

GLFW 3.3 for Go Installation GLFW C library source is included and built automatically as part of the Go package. But you need to make sure you have d

OpenGL with Golang 1.3k Dec 25, 2022
Go bindings for GLFW 3

GLFW 3.3 for Go Installation GLFW C library source is included and built automatically as part of the Go package. But you need to make sure you have d

OpenGL with Golang 1.4k Dec 27, 2022
Go cross-platform glfw library for creating an OpenGL context and receiving events.

glfw Package glfw experimentally provides a glfw-like API with desktop (via glfw) and browser (via HTML5 canvas) backends. It is used for creating a G

null 77 Sep 27, 2022
Flutter on Windows, MacOS and Linux - based on Flutter Embedding, Go and GLFW.

go-flutter - A package that brings Flutter to the desktop Purpose Flutter allows you to build beautiful native apps on iOS and Android from a single c

null 5.5k Jan 9, 2023
Compute shader in GO (using go-gl/glfw)

shadr (compute shader using go-gl/glfw) structure main.go contains intialisation

null 1 Jan 20, 2022
libsox bindings for go

gosox "SoX − Sound eXchange, the Swiss Army knife of audio manipulation" Go bindings for the libsox sound library For more information and documentati

Kristoffer Grönlund 124 Nov 22, 2022
Go bindings for the PortAudio audio I/O library

portaudio This package provides an interface to the PortAudio audio I/O library. See the package documentation for details. To build this package you

Gordon Klaus 559 Jan 1, 2023
Go bindings for libportmidi

portmidi Want to output to an MIDI device or listen your MIDI device as an input? This package contains Go bindings for PortMidi. libportmidi (v. 217)

Jaana Dogan 276 Dec 25, 2022