The size limits set on our XDG surface did not include the sizes of the
fallback decorations on all sides, when in use. This led to its content
area being too small.
Related to #2127
(cherry picked from commit a7b6f35500)
The handler for xdg_toplevel::configure treated the provided size as the
content area size when instead it is the size of the bounding rectangle
of the wl_surface and all its subsurfaces.
This caused the fallback decorations to try positioning themselves
outside themselves, causing feedback loops during interactive resizing.
Fixes#1991Fixes#2115Closes#2127
Related to #1914
(cherry picked from commit 0f5b095042)
The surface was resized and the size event was emitted before we had
sent xdg_surface::ack_configure. If user code then called some GLFW
function that commited the surface, those changes would all get applied
to the wrong configure event.
This postpones size changes until after the ack.
(cherry picked from commit e33db6d7aa)
The wayland-scanner output provides really nice, self-documenting
version macros, so we should use them whenever possible.
(cherry picked from commit ed39ff43f9)
If platform initialization failed before either timer fd member had been
set to -1 or a valid fd, termination would close stdin.
(cherry picked from commit 3bbb41eacc)
The window content scale event was emitted every time the window content
area was resized, even if its scale had not changed.
(cherry picked from commit 0b76e3a6f1)
The internal maximization state was not updated when an event was
received that the user had changed the maximization state of a window,
and no maximization events were emitted.
This affected both the GLFW_MAXIMIZED attribute and glfwRestoreWindow.
(cherry picked from commit f39ffefb6a)
These changes make GLFW fullscreen more consistent, but unfortunately
also make GLFW even more oblivious to user-initiated XDG shell
fullscreen changes.
Fixes#1995
(cherry picked from commit ddd087d662)
By default, the glfw3native.h header will include the platform-specific
headers necessary for the return types of GLFW native access functions.
Sometimes it is preferrable to declare those types
This commit adds support for the GLFW_NATIVE_INCLUDE_NONE macro, which
when defined disables the inclusion of all platform-specific headers.
Fixes#1348
(cherry picked from commit 05f6c13d11)
GLFW did not restore the previous Xlib error handler when removing its
own, instead resetting to the default handler.
This commit saves and restores the previous error handler.
None of this is thread-safe or could ever be.
Fixes#2108
(cherry picked from commit 26920a1a38)
The joystick code did not distinguish between the allocation status of
the GLFW joystick object and whether it is connection to an OS level
joystick object.
These are now tracked separately.
Fixes#2092
This is adapted to 3.3-stable from
2c204ab52e and
fd7e737216.
The modifier bits for lock keys were only set when the corresponding key
was reported as held down or latched, but not when it was released and
locked.
(cherry picked from commit e9c58bc181)
This avoids glfwCreateWindow emitting GLFW_PLATFORM_ERROR on Wayland
because shared code was calling unimplemented or unavailable platform
functions during final setup.
It also makes it consistent with the final setup of full screen windows.
This is adapted to 3.3-stable from
09653b8c54.
The code assumed that at least some data would be received via the INCR
mechanism and that, as a result, the string buffer would be allocated.
Bug found by Clang static analysis.
(cherry picked from commit 23e6e8e4b7)
The clipboard string should not be freed on SelectionClear. The user
may have received it from glfwGetClipboardString and it should remain
valid until the next call to a public clipboard string function.
(cherry picked from commit f60547ac80)
This adds support for file path drop events in text/uri-list format.
It is based on work by Pilzschaf in #2040.
Closes#2040
(cherry picked from commit 4cb36872a5)
The Wayland backend was the only one where half the window and input
related code was in the init module. As those bits want to share more
utility code with the window module, the interface between them grows.
To prevent that, this gathers nearly all window and input related code
into the window module.
This is adapted to 3.3-stable from
b7a3af9b79.