On macOS 10.15 Catalina and earlier, not having the resizable bit
cleared in NSWindowStyleMask in fullscreen leads to windows minimising
when clicked anywhere in the content area.
On all tested macOS versions it also causes the fullscreen window to be
resizable by the user.
Regression introduced by 0d599026d0.
Fixes#2377Closes#2405
(cherry picked from commit 8e9a5d29a8)
Mesa EGL requires the context version to be set to 2.0 or greater before
EGL_CONTEXT_OPENGL_NO_ERROR_KHR in the attribute list.
Without this, context creation via Mesa EGL with
EGL_CONTEXT_OPENGL_NO_ERROR_KHR set fails with EGL_BAD_ATTRIBUTE.
Fixes#2348
On macOS 10.15 Catalina and earlier, not having the resizable bit
cleared in NSWindowStyleMask in fullscreen leads to windows minimising
when clicked anywhere in the content area.
On all tested macOS versions it also causes the fullscreen window to be
resizable by the user.
Regression introduced by 0d599026d0.
Fixes#2377Closes#2405
The EGL_EXT_present_opaque extension is primarily a workaround meant for
Wayland, even if the language in it doesn't mention this. GLFW
previously always enabled this extension where supported. This caused
issues on X11 when running the Nvidia binary blob.
This commit ensures the extension is only enabled on Wayland.
Fixes#2365
This was adapted to 3.3-stable from
46cebb5081.
The occlusion state parts of NSWindow are OS X 10.9+ only but we still
(technically) support building for only 10.8.
Fixes#2161
(cherry picked from commit 5e4496cb42)
It is reportedly possible to get opposing directions of an XInput DPad
bit mask set simultaneously with some controllers.
This commit ensures that those values are not passed on to other parts
of GLFW.
This commit is based on the PR #2291 by @ PeterJohnson but with the
following changes:
- moved XInput-specific special case to XInput implementation
- attempt to preserve data by only masking out the invalid axis
- admin (credit, changelog, commit message)
Closes#2291
(cherry picked from commit 52405a9d59)
Shifted the documentation away from the term 'named keys' as something
different than keys that glfwGetKeyName will return a name for. The
already existing term 'key token' should now be used to refer to the
GLFW_KEY_* constants.
The associated term 'named mouse button' was also replaced with
'supported mouse button'.
The parts explaining which key tokens will return a valid scancode from
glfwGetKeyScancode have hopefully been clarified. This issue was
reported in #2055.
The GLFW_KEY_UNKNOWN constant has been moved out of the list of key
tokens to simplify and hopefully clarify the related documentation.
Various other keyboard key related edits were made, hopefully resulting
in improvements.
Related to #2055
(cherry picked from commit 9959dc69ca)
The shared function for reading back context attributes,
_glfwRefreshContextAttribs, did not check whether the newly created
context had been successfully made current. This violated the invariant
that the context TLS slot always points to a valid window and that its
context is current whenever _glfw.platform.getProcAddress is called.
Related to #2327
This was adapted to 3.3-stable from
fa0ea5c41f and
ddd92a4fa8.
The EGL_EXT_present_opaque extension is primarily a workaround meant for
Wayland, even if the language in it doesn't mention this. GLFW
previously always enabled this extension where supported. This caused
issues on X11 when running the Nvidia binary blob.
This commit ensures the extension is only enabled on Wayland.
Fixes#2365
It is reportedly possible to get opposing directions of an XInput DPad
bit mask set simultaneously with some controllers.
This commit ensures that those values are not passed on to other parts
of GLFW.
This commit is based on the PR #2291 by @ PeterJohnson but with the
following changes:
- moved XInput-specific special case to XInput implementation
- attempt to preserve data by only masking out the invalid axis
- admin (credit, changelog, commit message)
Closes#2291
Shifted the documentation away from the term 'named keys' as something
different than keys that glfwGetKeyName will return a name for. The
already existing term 'key token' should now be used to refer to the
GLFW_KEY_* constants.
The associated term 'named mouse button' was also replaced with
'supported mouse button'.
The parts explaining which key tokens will return a valid scancode from
glfwGetKeyScancode have hopefully been clarified. This issue was
reported in #2055.
The GLFW_KEY_UNKNOWN constant has been moved out of the list of key
tokens to simplify and hopefully clarify the related documentation.
Various other keyboard key related edits were made, hopefully resulting
in improvements.
Related to #2055
The shared function for reading back context attributes,
_glfwRefreshContextAttribs, did not check whether the newly created
context had been successfully made current. This violated the invariant
that the context TLS slot always points to a valid window and that its
context is current whenever _glfw.platform.getProcAddress is called.
Related to #2327
The Wayland implementation of glfwWaitEvents* keeps waiting until it
sees evidence that a significant event has been processed. However,
this included updating an animated cursor (not a significant event)
but did not include previously buffered Wayland events or libdecor
events (definitely significant events).
This commit corrects these cases.
(cherry picked from commit d097e35743)
When setting the visibility of a libdecor frame on a compositor that
supports XDG decorations, libdecor 0.1 will update the geometry of the
XDG surface. GLFW attempted to set the visibility before having told
libdecor what size the content area is. This caused a Wayland protocol
error when libdecor attempted to set the window size to 0x0.
This commit adds setting the content area size for the libdecor frame
directly after creation, allowing libdecor to know what it's doing.
(cherry picked from commit 23e40548b1)
Much of libdecor is initialized only after certain events have been
received from the compositor and some parts of libdecor 0.1 are unsafe
to use until this delayed initialization has completed.
Since libdecor does not provide an API to query if or be notified when
this has happened, GLFW processed events until its newly created
libdecor frame had created its XDG shell objects.
This commit switches to using a generic Wayland sync point created just
after libdecor (and presumably its plugin) has set up its delayed
initialization, instead of relying on the more specific implementation
detail mentioned above.
It also makes this wait mandatory before the first libdecor frame is
created instead of a pre-condition for certain libdecor frame calls,
hopefully removing even more dependence on implementation details.
(cherry picked from commit 9fdc425931)
The Wayland implementation of glfwWaitEvents* keeps waiting until it
sees evidence that a significant event has been processed. However,
this included updating an animated cursor (not a significant event)
but did not include previously buffered Wayland events or libdecor
events (definitely significant events).
This commit corrects these cases.
When setting the visibility of a libdecor frame on a compositor that
supports XDG decorations, libdecor 0.1 will update the geometry of the
XDG surface. GLFW attempted to set the visibility before having told
libdecor what size the content area is. This caused a Wayland protocol
error when libdecor attempted to set the window size to 0x0.
This commit adds setting the content area size for the libdecor frame
directly after creation, allowing libdecor to know what it's doing.
Much of libdecor is initialized only after certain events have been
received from the compositor and some parts of libdecor 0.1 are unsafe
to use until this delayed initialization has completed.
Since libdecor does not provide an API to query if or be notified when
this has happened, GLFW processed events until its newly created
libdecor frame had created its XDG shell objects.
This commit switches to using a generic Wayland sync point created just
after libdecor (and presumably its plugin) has set up its delayed
initialization, instead of relying on the more specific implementation
detail mentioned above.
It also makes this wait mandatory before the first libdecor frame is
created instead of a pre-condition for certain libdecor frame calls,
hopefully removing even more dependence on implementation details.
The current wording states that all keys have synthetic key release
events generated after focus is lost, but keys that aren't named
don't have any state held, so no such events are generated for them.
The new wording clarifies that only named keys have the events generated
for them.
(cherry picked from commit dbe810e403)
Passing a context-less window to a function that requires a context only
emits a harmless GLFW_NO_WINDOW_CONTEXT error.
(cherry picked from commit 0bd3e879e1)
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
(cherry picked from commit 509f4131be)
Camilla Löwy
FuzzyQuills
lo-v-ol
Peter Johnson
Doug Binks
Grzesiek11
Michael Skec