A window resize action that also resulting in the window being moved did
not emit any window positions events, as the position of real
ConfigureNotify events was ignored. The real events use parent
coordinates instead of root coordinates so this adds parent tracking and
conditional translation.
Fixes#1613.
This removes the final dependency on CoreVideo, using a display link to
get the refresh rate of monitors where Core Graphics report a refresh
rate of zero. Instead we now query the I/O registry directly, similarly
to what the display link does at creation.
Thanks to @OneSadCookie for pointers to this solution.
The display link query is not specific to any particular display mode
and so only needs to be done once.
The next step is to replace the display link altogether by querying
IOKit directly, which is what the display link does.
CLOCK_MONOTONIC should not be used as a feature macro. The POSIX
feature macros are provided by unistd.h. CLOCK_MONOTONIC is provided by
time.h. CLOCK_MONOTONIC requires _POSIX_C_SOURCE >= 199309L on some
systems.
Polling the event queue before NSApp had been allowed to finish
launching, in our case by starting our self-terminating run loop,
triggered an assertion inside NSApplication.
This fix, which makes all event processing functions capable of starting
it, makes that assertion less likely.
A more Cocoa-friendly fix would be to finish launching NSApp during
glfwInit and let people annoyed by the menu bar disabled it with
GLFW_COCOA_MENUBAR. That may not be suitable for 3.3-stable, though.
Fixes#1543.
That way the application only sees the cursor moving when it is inside
of its area, it won’t go back to the top or left side when trying to
resize the window or just hovering the fallback decorations.
Previously, any pointer motion in the window decorations when using the
fallback implementation would obtain the wl_cursor again, and do the
attach danse for no benefit.
This will ultimately allow animated cursors to not reset to the first
frame on motion, once these will be implemented.
This falls back to calculating the monitor physical size from the
current resolution and the default X11 DPI when the physical size
returned by RandR is zero.
On macOS a destroyed window remained on screen until the next time
events were processed. This makes the behavior more consistent with
other platforms.
Fixes#1412.
The SDL2 2.0.5+ controller GUID 03000000790000000600000000000000 matches
many devices with different layouts and element counts but with the same
chipset. This issue is still being resolved upstream. In the meantime
this removes those mappings from GLFW to avoid confusion and errors.
SDL upstream issue: https://bugzilla.libsdl.org/show_bug.cgi?id=4545
Related to #1583.
This is a temporary fix while we determine if the color key workaround
should be removed completely. See issue thread for discussion.
Related to #1512.
KDE sometimes removes the Xft.dpi resource when it would be set to the
X11 default value of 96, causing GLFW to fall back to a value calculated
from the core display sizes in pixels and mm in a desktop environment
that supports Xft.dpi.
This moves to a hardcoded fallback value of 96 on the assumption that
there are more people running KDE with 96 DPI than there are people
running desktop environments that do not support Xft.dpi.
All of this is terrible please send help.
Fixes#1578.
This fixes the enabling of window decorations after creation. Instead
of removing the _MOTIF_WM_HINTS property, we now set or unset the
MWM_DECOR_ALL bit of the decorations field.
Fixes#1566.
Replaces `VERSION_GREATER_EQUAL` with `VERSION_EQUAL OR
VERSION_GREATER`. `VERSION_GREATER_EQUAL` was only added in CMake 3.7.
Fixes#1584.
Closes#1585.
The `monitorCount` member in the `_GLFWlibrary` struct is of type `int`, so the `for` loop iterating over it should also use the type `int`.
Closes#1572.
This enables compilation as C99 where supported by the compiler.
A workaround with per-compiler hardcoded flags is used for CMake 3.0,
which does not support the C_STANDARD target property.
Fixes#1560.
Closes#1576.
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.
This solution of one display link per window is far from ideal but is
still better than no solution.
As a side-effect this fixes swap interval breaking being ignored for
occluded windows on earlier versions of macOS.
Fixes#680.
Fixes#1337.
Related to #1417.
Fixes#1435.
This fixes OpenGL swap interval (vsync) on macOS 10.14 Mojave by using
CVDisplayLink to synchronise to the monitor refresh rate rather than
setting NSOpenGLContextParameterSwapInterval.
Solution based on advice provided by @rcgordon.
Closes#1417.
This is another small step towards having GLFW play nice with other
toolkits sharing the same process, including AppKit.
Any macOS platform function that touches Cocoa must now wrap itself in
an autoreleasepool block.
Since GLFW no longer provides an autoreleasepool outside of its
functions, THIS MAY BREAK EXISTING CODE MIXING GLFW AND COCOA. Sorry!
Please add your own autoreleasepool blocks as needed.
Fixes#1107.
Closes#1114.
This intersects the global work area from _NET_WORKAREA with the monitor
viewport. The monitor viewport falls back to the core display
dimensions where working RandR is missing. The _NET_WORKAREA query is
now checked for success. The _NET_WORKAREA extent array is now indexed
by _NET_CURRENT_DESKTOP. The _NET_WORKAREA atom is now checked for
availability.
Related to #1322.
This renames 'raw input' to 'raw mouse motion' as there are other kinds
of raw input. The update path is restructured to avoid reinitializing
all of disabled cursor mode. Modification of shared state is moved out
into shared code. Raw mouse motion is disabled by default for
compatibility.
Related to #1401.
We now keep track of the fullscreen and activated state and only iconify
if we were previously fullscreen and now we are either not fullscreen or
not activated anymore.
This is the proper way to do it, compared to the previous hack where we
didn’t iconify only if it was the first configure event received.
I was getting an error in this cmake file when using 3.10.2 on linux.
Here was the error message I was getting:
[cmake] CMake Error at external/glfw/src/CMakeLists.txt:82 (if):
[cmake] if given arguments:
[cmake]
[cmake] "STREQUAL" "GNU" "OR" "STREQUAL" "Clang"
[cmake]
[cmake] Unknown arguments specified
Adding the quotes around the cmake variables seems to do the trick. That
was also done with the STREQUAL condition earlier on line 66.
Closes#1411.
The application delegate needs to be set at init to receive monitor
events before window creation. Menu creation is moved to
applicationWillFinishLaunching: to play nicer with other toolkits in the
same process.
Related to #1317.
This makes glfwSetGamma generate a gamma ramp of the same size as the
monitor's current ramp, which will avoid failure on non-256 entry
monitors on X11 and avoid ramp interpolation on macOS.
Closes#1387.
Fixes#1388.
Commit 9c513346ad ("Gamma will never be
supported on Wayland") made it clear that it cannot be implemented, so
this removes the TODO markers and rewords the error messages.
Related to #1387.
Older versions did not provide fmin or fmax. This adds internal
versions of fminf and fmaxf that should not be confused with
standards compliant implementations.
This adds reporting of those Caps Lock key events that cause the lock
state to change.
The full fix involving IOHID is being worked on in #1368.
Related to #1368.
Closes#1373.
This removes the GLFW NSApplication subclass as a step towards better
coexistence with other libraries that touch Cocoa.
This moves application object creation to platform init to allow event
processing before window creation.
Related to #1317.
This has the advantage that the user may override e.g. the include
location, and the correct libdir (lib, lib64, lib/something) is
automatically determined.
Closes#1367.
click events would have an incorrect position after changing workspace,
if the mouse didn't move in between.
(Another example where this matters is a new window, if it appears under
the cursor, clicking would lead the application to think the user clicked
at 0,0)
