Open bgribble opened 8 months ago
Hey @bgribble,
you are using GLFW 3.3.9, not GLFW 3.4, so that's why that case isn't handled by GLFW. The confusion is understandable, though:
GLFW_VERSION_MAJOR
, GLFW_VERSION_MINOR
and GLFW_VERSION_REVISION
, which are wrapped as glfw.VERSION_MAJOR
, etc represent the version of the GLFW header available at compile time. This concept doesn't really exist for Python, I have simply wrapped them as they are and use the major/minor versions to represent what has been wrapped.glfw.get_version()
represents the runtime version of GLFW, which is actually used when you run the program.This package provides wrappers for GLFW 3.4, however due to buildsystem incompatibilities, I cannot build 3.4 to be included in the wheels (short version, wheels have specific build system images, which in are too old for features used by 3.4, some more info in issue #77 ), so instead I provide the latest version I can still build for them, 3.3.9.
When/if those issues get resolved, I will update the package with GLFW 3.4. Until then, if you wish to use those newer features, download GLFW from glfw.org, either as a pre-built binary or as source code to compile for yourself, or use a version from a package manager.
This is in version 2.7.0 of the pyGLFW package, against version 3.4.0 of glfw.
I have manually searched for and removed any other versions of glfw on my (Debian unstable, amd64) machine.
The enum for
WAYLAND_APP_ID
is in the package, but the underlying C lib throws an error:From looking at the GLFW source that error appears to come from falling through the switch statement just above, which for version 3.4.0 does include
WAYLAND_APP_ID
. So I thought that maybe the Python bindings were pointing to an incorrect version of libglfw, but I can't find another one on my system.I do notice that
glfw.get_version()
returns(3, 3, 9)
rather than the expected(3, 4, 0)
so maybe that IS the problem somehow?