glfwGetKeyName emitted GLFW_INVALID_VALUE when passed GLFW_KEY_UNKNOWN
and any scancode not associated with a key token on that platform.
This causes physical keys with no associated key token to emit
GLFW_INVALID_VALUE when the key and scancode are passed directly from
the key event to glfwGetKeyName. This breaks the promise made in the
reference documentation for glfwGetKeyName.
This commit removes that error for the whole range of valid scancodes.
Fixes#1785
This is primarily a workaround for a GLFW application reading and/or
writing to the clipboard in rapid succession and catching up with the
Windows Clipboard History, which also has to contend for the lock.
The bitmask passed to MsgWaitForMultipleObjects was missing
QS_SENDMESSAGE, causing glfwWaitEventsTimeout not to return when the
thread received messages sent from other threads.
Fixes#2408
This adds window hints for the initial position, in screen coordinates,
of a window. The special value GLFW_ANY_POSITION means the window
manager will be allowed to position the window.
It is not possible to set window positions on Wayland and GLFW will
always behave as if these hints are set to GLFW_ANY_POSITION.
Fixes#1603Fixes#1747
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.
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.
Operations that take an instance handle should be passed the handle of
whatever module we are inside instead of blindly passing the handle of
the executable.
This commit makes GLFW retrieve its own instance on initialization.
This makes the most difference for window classes, which are
per-instance. Using the executable instance led to name conflicts if
there were several copies of GLFW in a single process.
Note that having this is still a bad idea unless you know what things to
avoid, and those things are mostly platform-specific. This is partly
because the library wasn't designed for it and partly because it needs
to save, update and restore various per-process and per-session settings
like current context and video mode.
However, multiple simultaneous copies of GLFW in a single Win32 process
should now at least initialize, like is already the case on other
platforms.
Fixes#469Fixes#1296Fixes#1395
Related to #927
Related to #1885
Alt+PrtSc emits a different scancode than just PrtSc. Since the GLFW
API assumes each key corresponds to only one scancode, this cannot be
added to the keycodes array.
Instead we replace the scancode at the point of entry.
Fixes#1993
The normal way of maximizing a window also makes it visible. This
implements window maximization manually for when the window passed to
glfwMaximizeWindow is hidden.
This will very likely not be forward-compatible and should be replaced.
The window content scale correction at creation overwrote the inital,
more pleasant placement of the window by CW_USEDEFAULT, if the window
was created with GLFW_MAXIMIZED set. This is because the translation
to screen coordinates was done using the current position, not the
position from the restored window rect.
A window created maximized and undecorated would cover the whole monitor
Windows placed it on instead of just that monitor's workarea.
This commit adjusts the maximized rect to cover just the workarea,
similar to how undecorated windows that become maximized are handled
during WM_GETMINMAXINFO.
Fixes#1806
This adds compile-time support for multiple platforms and runtime
detection of them. Window system related platform functions are now
called from shared code via the function pointer struct _GLFWplatform.
The timer, thread and module loading platform functions are still called
directly by name and the implementation chosen at link-time. These
functions are the same for any backend on a given OS, including the Null
backend.
The platforms are now enabled via CMake dependent options following the
GLFW_BUILD_<platform> pattern instead of a mix of automagic and ad-hoc
option names. There is no longer any option for the Null backend as it
is now always enabled.
Much of the struct stitching work in platform.h was based on an earlier
experimental branch for runtime platform selection by @ronchaine.
Every platform function related to windows, contexts, monitors, input,
event processing and Vulkan have been renamed so that multiple sets of
them can exist without colliding. Calls to these are now routed through
the _glfw.platform struct member. These changes makes up most of this
commit.
For Wayland and X11 the client library loading and display creation is
used to detect a running compositor/server. The XDG_SESSION_TYPE
environment variable is ignored for now, as X11 is still by far the more
complete implementation.
Closes#1655Closes#1958
This adds the glfwInitAllocator function for specifying a custom memory
allocator to use instead of the C runtime library.
The allocator is a struct of type GLFWallocator with fields
corresponding to malloc, realloc and free, while the internal API
corresponds to calloc, realloc and free.
Heap allocation calls are filtered before reaching the user-provided
functions, so deallocation of NULL and allocations of zero bytes are not
passed on, reallocating NULL is transformed into an allocation and
reallocating to size zero is transformed into deallocation.
The clearing of a new block to zero is performed by the internal
calloc-like function.
Closes#544.
Fixes#1628.
Closes#1947.
GLFW_SCALE_TO_MONITOR had no effect on Windows 8.1 up to and including
Windows 10 version 1607 (Anniversary Update), despite those having
support for per-monitor DPI.
That done was to avoid handling systems that have non-client scaling,
introduced in Windows 10 version 1607, without reliable overriding of
the new window size, introduced in Windows 10 version 1703 (Creators
Update). Both are needed to keep the content area at a fixed size for
windows that have GLFW_SCALE_TO_MONITOR disabled.
This change enables window rescaling on Windows 8.1 and all later
versions but disables non-client scaling for unscaled windows on Windows
10 version 1607. Versions after 1607 are unaffected.
Fixes#1511.
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.
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.
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.
