A regression introduced by b889aa7841
broke the special handling of numpad keys for the non-XKB fallback path.
The non-functional remains were later removed. This restores the
original behavior.
This fixes the issue where function keys would be reported as
GLFW_KEY_UNKNOWN if XKB was available and one of the configured keyboard
layouts was Arabic.
This is only part of #1598, because the full patch removed parts of the
fallback path for when XKB is unavailable.
Closes#1598.
The non-root parent window owned by the WM could be destroyed before we
process the ConfigureNotify event using the cached parent handle.
Bug was found by unmapping a decorated window.
This like all uses of the Xlib error handler is not thread safe and
there is nothing we can do about that short of moving to XCB.
Fixes#1633.
This adds support for the XIM instantiate and destroy callbacks, letting
GLFW detect both when the current input method disappears and when a new
one is started.
Tested with ibus.
This moves the remaining bits of NSApplication initialization into
_glfwPlatformInit. As a side-effect of this, any command-line program
initializing GLFW will get a menu bar, which is not ideal.
If this has happened to you and a bisect led you here, please see the
GLFW_COCOA_MENUBAR init hint introduced in GLFW 3.3.
If this patch is a terrible idea, please get in touch in the 3.4 release
timeframe.
This is a replacement for 6e6805000a,
which attempts to preserve the existing menu bar creation behavior for
the 3.3-stable branch.
Fixes#1649.
Some synthetic key messages come with a scancode of zero, causing them
to be translate to GLFW_KEY_UNKNOWN. This fills in the missing scancode
by translating the provided virtual key.
Rather than further complicate a single-use function, its body is merged
into the key message handler.
Fixes#1623.
The Win+V hotkey brings up a clipboard history IME that consumes the key
release. This adds left and right Super to the modifier keys manually
polled for undetected release during event processing.
Fixes#1622.
If the application is not linked against the Vulkan loader and relies on
a third-party loader library or glfwGetInstanceProcAddress, then our
call to dlopen will fail without a custom dyld environment variable.
This adds a fallback of looking in the directory of the main executable,
which matches the bundle structure recommended by the Vulkan SDK, making
that finally work out of the box for fully dynamic loading.
When the WM does not support EWMH or there is no WM running, GLFW falls
back to XSetInputFocus, which will emit BadMatch if the window is not
viewable, which will terminate the program.
Bug spotted on IRC.
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.
