The `name` member in the `_GLFWmonitorWayland` struct is used in two places. It is assigned the value from a variable of type `uint32_t` and is compared to another variable of type `uint32_t`, so `name` should also have the same type.
Closes#1569.
The `size` member in the `GLFWgammaramp` struct is of type `unsigned int`, so the `for` loop iterating over it should also use the type `unsigned int`.
Closes#1541.
The window rect adjustment for content scale broke the initial, correct
maximization performed when creating the window with WS_MAXIMIZE. This
switches to updating the restored rect instead of the current rect.
Fixes#1499.
Closes#1503.
For users with multiple keyboard layouts configured, glfwGetKeyName
works fine only with the primary layout. Switching layouts results in
changing the group index. This commit querries the current group index
when initializing keyboard input and keeps track of any change to it.
As a result the scancode -> keyname mapping may change while the program
is running (needs to be documented).
Fixes#1462.
Closes#1528.
MSVC 2019 complains that the code at line 1744
(`GetMonitorInfo(window->monitor->win32.handle, &mi);`) can potentially
dereference a null pointer. The compiler is wrong in this case (it has
not spotted that `monitor` and `window->monitor` must be equal), but
I think it makes sense for our non-NULL test to be on the variable we
actually use rather than the one it was set from.
Related to #1491.
The EWMH feature detection atoms are now named and loaded the same way
as other X11 atoms. Detection is now performed after all
non-conditional atoms have been loaded. The EWMH detection now has
hopefully more readable comments.
This protocol is part of the core Wayland, but it is pretty badly
designed and is missing quite a few features, and is in the process of
being phased out in compositors. Its support in GLFW requires
duplicating pretty much every single window management codepath.
This bumps the required compositor versions to the ones which have
implemented xdg-shell, approximately two years ago, which seems sensible
to me.
Window relative mouse locations provided via NSWindow and NSEvent are
based at 0,1 while screen relative locations use 0,0. Incorrect
handling of this had crept into other coordinate transformations. Note
that most of these errors canceled each other out, so the reported
positions of windows, monitors and work areas are unaffected. This
corrects the cursor position for glfwGetCursorPos and glfwSetCursorPos.
Fixes#1461.
DWM composition is always enabled on Windows 8 and later, so there's no
need to call DwmIsCompositionEnabled on those platforms.
Fixes#1452.
Closes#1453.
Luflosi
Camilla Löwy
luz.paz
Camilla Löwy
httpdigest
Ave Milia
Leon Linhart
Denis Bernard
A. Tombs
Konstantin Podsvirov
Emmanuel Gil Peyrot
Cliff Smolinsky