Normally I'd be against such a double negative, but it seems more
intuitive in this case - enabling new handling makes more sense than
disabling old handling.
Change 'supported mouse buttons' to 'mouse button tokens', which makes a
lot more sense. Also improve the wording of the new mouse button
documentation overall.
Provide an initialization hint for the removal of the mouse button
limit, as users might have assumed GLFW_MOUSE_BUTTON_LAST to be the last
possible mouse button, and not the last named mouse button.
The current wording states that all mouse buttons have synthetic release
events generated after focus is lost, but buttons that aren't named
don't have any state held, so no such events are generated for them.
It's possible for at least the Wayland and X11 platforms to report mouse
button codes above the 8 named by GLFW. There is however an arbitrary
limitation in place that causes them to never be reported to the API
consumer. This change removes that limitation.
In a Parallels VM wglGetPixelFormatAttribivARB returns fewer pixel
formats than DescribePixelFormat. This broke context creation on
Windows in Parallels since the changes in
2c0f34b60f. The previous version of the
code worked accidentally.
This adds a workaround by iterating through the minimum of both counts.
It should have no effect when running on conforming implementations.
Tested on Parallels by @ dougbinks.
Closes#2191Fixes#2406Fixes#2467
The native access functions for monitor objects did not check whether
the correct platform was initialized and would return invalid handles if
it was not.
This implements window attention requests via the xdg-activation-v1
protocol.
This was updated by @ elmindreda to work with recent Wayland related
changes to the main branch:
- Switched to current way of handling Wayland protocol files
- Added the xdg-activation-v1.xml protocol file to deps/wayland
- Added missing macros to rename protocol interface globals
The protocol file was copied from wayland-protocols 1.33.
Closes#2287
This changes the default platform for Unix-like systems (other than
macOS) from only X11 to Wayland and X11. It also removes the backward
compatibility with the older GLFW_USE_WAYLAND CMake option.
If a bisect took you here because your build broke, hello, sorry, set
the GLFW_BUILD_WAYLAND or GLFW_BUILD_X11 CMake option to disable the
associated platform.
This can be done when configuring GLFW with CMake, from a higher-level
CMakeLists.txt if GLFW is part of your project, or at any point after
configuration by updating the CMake cache with the command-line tool or
the GUI.
The next step is to make Wayland the run-time default when enabled, but
that will hopefully not break any builds.
Related to #2439
The list of compile-time dependencies on FreeBSD lacked evdev-proto.
Unlike on Linux, the input-event-codes.h header file was not implicitly
included on FreeBSD.
Fixes#2445
glfwGetKeyName emitted GLFW_INVALID_VALUE when passed GLFW_KEY_UNKNOWN
and any scancode not associated with a key token on that platform.
This causes physical keys with no associated key token to emit
GLFW_INVALID_VALUE when the key and scancode are passed directly from
the key event to glfwGetKeyName. This breaks the promise made in the
reference documentation for glfwGetKeyName.
This commit removes that error for the whole range of valid scancodes.
Fixes#1785
We can finally have the compiler verify that the values go to the
correct struct member.
With this commit GLFW no longer compiles with Visual Studio 2012 or
earlier. If you must compile GLFW on Windows XP, check out MinGW-w64.
Fixes#2465
The GLFW_PLATFORM_UNAVAILABLE error was not listed for those native
access function that can emit it.
The order of errors for many functions in glfw3native.h did not match
the order used in glfw3.h.
The documentation for GLFW_PLATFORM_UNAVAILABLE was a little bit terse.
