Content scale events would be emitted when a window surface entered or
left an output, but not when one of a window's current outputs had its
scale changed.
GLFW would report a monitor as connected each time its wl_output
received an update, for example if its scale changed.
This would also cause the monitor to be added to the monitor array
again, causing glfwTerminate to segfault when it attempted to destroy
its already destroyed wl_output.
This is a temporary local fix to have updates to GLFW_DECORATED mostly
work as intended. The whole decoration state machine needs to be
restructured, but not by this commit.
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
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
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.
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.
These changes make GLFW fullscreen more consistent, but unfortunately
also make GLFW even more oblivious to user-initiated XDG shell
fullscreen changes.
Fixes#1995
By using window class atoms, we only need to mention each window class
name once, also removing the need to define _GLFW_WNDCLASSNAME. It can
still be defined by the user as before.
The current window procedure needs to deal with messages both for user
created windows and the hidden helper window.
This commit separates out the device message handling of the helper
window, allowing both window procedures to be less complicated.
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
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
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.
This avoids glfwCreateWindow emitting GLFW_FEATURE_UNAVAILABLE or
GLFW_FEATURE_UNIMPLEMENTED 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.
There will not currently be more than one set of threading or timer APIs
selected regardless of how many window systems are enabled, so there is
no need for this extra complexity.
Versions of wayland-scanner prior to 1.17.91 named every global array of
wl_interface pointers 'types', making it impossible to combine several
unmodified private-code files into a single compilation unit.
This overrides that name with a macro for each file, allowing them to
coexist.
Fixes#2016Closes#2032
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.
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.
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.
