On Windows 7, when GLFW framebuffer transparency and the DWM are enabled
but DWM transparency is disabled (i.e. when the Transparency setting is
disabled under Personalization > Color), the contents of the framebuffer
is combined with the last frame using additive blending instead of
replacing the previous contents.
This commit limits GLFW framebuffer transparency on Windows 7 to when
DWM transparency is enabled, removing the previous workaround of setting
a layered window color key that led to rendering artifacts.
Fixes#1512.
This makes joystick support initialize the first time a joystick
function is called, including those gamepad functions that are layered
on top of joystick functions.
Related to #1284.
Related to #1646.
Returning HTTRANSPARENT from WM_NCHITTEST does cause the window to be
transparent for some hit-testing APIs but does not make it pass mouse
input through to whatever window is below it.
For that to work on modern Windows, the window needs to be both layered
and extended-window-style-transparent.
Additional logic changes to ensure mouse input passthrough, framebuffer
transparency and window opacity are mindful of one another when
modifying WS_EX_LAYERED.
Related to #1568.
The client clip region was left in place when mouse passthrough was
disabled, leading to missing mouse input if the window grew beyond it.
Related to #1568.
This adds the GLFW_MOUSE_PASSTHROUGH window hint and attribute for
controlling whether mouse input passes through the window to whatever
window is behind it.
Fixes#1236.
Closes#1568.
It seems it has not been possible to compile GLFW on systems without the
UTF-8 extensions to Xlib since a0a5cc57df
was merged five months ago. The UTF-8 extension functions were
introduced with XFree86 4.0.2 in December 2000 and are likely widely
available at this point.
This removes the locale-dependent fallback paths and uses the UTF-8
extension functions where available.
Background: The IM will filter out key events, instead sending exact
duplicate events that are not filtered. It does not send these for
every event, however, so the duplicate events cannot be relied on for
key input. Instead we need to identify and discard them. Since they
are identical, they have the same timestamp as the originals.
The previous duplicate event detection would consume unrelated key
events if the keys were pressed simultaneously, as it only tracked
a single timestamp.
This fixes that issue for any combination of keys, at the expense of
a 1 KB array per GLFW window.
This fix is a stopgap until explicit IME support is done.
Based on #1472 by @LucaRood.
Fixes#1112.
Fixes#1415.
Fixes#1616.
Fixes#1663.
Closes#1472.
This adds GLFW_CONTEXT_DEBUG as a preferred alias for
the GLFW_OPENGL_DEBUG_CONTEXT window hint, as debug contexts are
defined for both OpenGL and OpenGL ES.
Related to #1720.
This adds support for EGL_EXT_platform_base and its associated X11 and
Wayland extensions, allowing us to explicitly tell EGL which window
system we are using.
This is based on work by @linkmauve in #1691.
Closes#1691.
This makes the null platform behave more like an actual stub. More
queryable state is tracked and there is even a fake monitor with one
whole fake video mode.
This fixes a race between the key repeat logic and the surface leave
event handler, which could result in repeated keys being reported with
a window of NULL.
Fixes#1704.
This adds two new error codes: GLFW_FEATURE_UNAVAILABLE for when
a GLFW feature cannot be reasonably implemented on that platform, and
GLFW_FEATURE_UNIMPLEMENTED for when it can be but has not been yet.
This replaces the current situation where the Wayland code emitted
GLFW_PLATFORM_ERROR in both cases while the macOS code silently did
nothing.
If your application exits on any GLFW error, these error codes should at
least be easy to filter out from that behavior.
Ideally, GLFW_FEATURE_UNAVAILABLE should be rare and
GLFW_FEATURE_UNIMPLEMENTED should never be emitted at all.
Fixes#1692.
These are harmless errors but the code was worth fixing just to reduce
confusion and be more explicit. E.g. using a different variable name
for a new variable of a different type in win32_joystick.c.
Closes#1700.
When compiling with `-Wall` and `-pedantic-errors`, gcc complains with
```
warning: ISO C does not support the '%m' gnu_printf format [-Wformat=]
```
because the `%m` conversion specifier is a GNU extension.
Closes#1702.
The only two EGL implementations on macOS are Swiftshader and ANGLE.
While Swiftshader supports both `NSView` and `CALayer` as
`EGLNativeWindowType`, ANGLE supports only `CALayer`. Furthermore
Swiftshader's OpenGL ES frontend is deprecated in favor of using ANGLE's
Vulkan backend on top of Swiftshader's Vulkan frontend.
This means that on macOS `EGLNativeWindowType` should be a `CALayer` for
compatibility with ANGLE.
Fixes#1169.
Closes#1680.
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.
