On systems lacking the EGL_EXT_present_opaque extension, some
compositors treat any buffer with an alpha channel as per-pixel
transparent.
This commit ignores any EGLConfig with an alpha channel if the extension
is missing and the window is created with GLFW_TRANSPARENT_FRAMEBUFFER
set to false.
This is technically not a breaking change since GLFW_ALPHA_BITS is not
a hard constraint, but it is still going to inconvenience anyone using
the framebuffer alpa channel to store other kinds of data.
Related to #1895
(cherry picked from commit ef6c9d8b4f)
The cursor theme was only loaded if the chosen seat had a mouse
(wl_pointer) during initialization. If a mouse was connected only after
glfwInit, there would be no cursor theme but the rest of the cursor
related code assumed one had already been loaded.
This also moves the details of cursor theme loading out into a separate
function to declutter platform init.
Because the original cursor theme loading code checked whether we got
a wl_shm, and because the rest of the code just assumes we have
a wl_shm, initialization will now fail if there isn't one.
Fixes#1450
(cherry picked from commit 71be34a6c3)
Whenever GLFW changed the window style mask, a new mask was created
from scratch based on the attributes set on the GLFW window object.
This caused us to potentially clear unrelated window style bits.
This was always wrong but became a critical issue when Cocoa began
throwing an exception if an application cleared the
NSWindowStyleMaskFullScreen while the window is in macOS fullscreen.
This commit reworks all style mask editing so it only changes the
relevant bits, preserving all others.
This is only a narrow bug fix to prevent crashes, intended for the
stable branch. Our interaction with macOS fullscreen is still very
poor. The next step after this is a set of patches that improve the
interaction between the current API and macOS fullscreen.
Fixes#1886Fixes#2110
(cherry picked from commit 0d599026d0)
The reasoning here is that glfwRestoreWindow will change nothing for
a windowed non-resizable window on Cocoa, and silently refusing to
maximize seems slightly more like something other platforms would do.
This is possibly either the right thing to do or the wrong one.
(cherry picked from commit 6f8ec4075b)
On a compositor that supports server-side decorations, they were always
enabled in windowed mode, even if GLFW_DECORATED was cleared.
(cherry picked from commit f35e2274cb)
When showing a window that had already been shown once (and so already
had its shell objects), GLFW would attach a new buffer and commit it
before waiting for the next configure event. This was a violation of
the XDG shell protocol.
This was allowed to work as intended on GNOME and KDE without error.
However wlroots based compositors would (correctly) emit an error.
Unfortunately, I haven't been able to find a way to get both KDE, GNOME
and Sway to send the configure event we need in order to map the
wl_surface again while keeping our existing shell objects, so with this
commit we now create them for each call to glfwShowWindow and destroy
them for each call to glfwHideWindow.
Fixes#1268
(cherry picked from commit 83a134a92f)
If a window was created as maximized, or created as hidden and then
iconified or maximized before first being shown, that state was lost and
the window was shown as restored.
(cherry picked from commit 77819c0c54)
The aspect ratio was applied during resize but any call to
glfwSetWindowAspectRatio emitted a GLFW_FEATURE_UNIMPLEMENTED error.
(cherry picked from commit 91f18fb576)
Content scale events would be emitted when a window surface entered or
left an output, but not when one of a window's current outputs had its
scale changed.
(cherry picked from commit e37ba80b13)
GLFW would report a monitor as connected each time its wl_output
received an update, for example if its scale changed.
This would also cause the monitor to be added to the monitor array
again, causing glfwTerminate to segfault when it attempted to destroy
its already destroyed wl_output.
(cherry picked from commit c3ad3d49ed)
This is a temporary local fix to have updates to GLFW_DECORATED mostly
work as intended. The whole decoration state machine needs to be
restructured, but not by this commit.
(cherry picked from commit 229d628ec4)
The size limits set on our XDG surface did not include the sizes of the
fallback decorations on all sides, when in use. This led to its content
area being too small.
Related to #2127
(cherry picked from commit a7b6f35500)
The handler for xdg_toplevel::configure treated the provided size as the
content area size when instead it is the size of the bounding rectangle
of the wl_surface and all its subsurfaces.
This caused the fallback decorations to try positioning themselves
outside themselves, causing feedback loops during interactive resizing.
Fixes#1991Fixes#2115Closes#2127
Related to #1914
(cherry picked from commit 0f5b095042)
If platform initialization failed before either timer fd member had been
set to -1 or a valid fd, termination would close stdin.
(cherry picked from commit 3bbb41eacc)
The window content scale event was emitted every time the window content
area was resized, even if its scale had not changed.
(cherry picked from commit 0b76e3a6f1)
The internal maximization state was not updated when an event was
received that the user had changed the maximization state of a window,
and no maximization events were emitted.
This affected both the GLFW_MAXIMIZED attribute and glfwRestoreWindow.
(cherry picked from commit f39ffefb6a)
These changes make GLFW fullscreen more consistent, but unfortunately
also make GLFW even more oblivious to user-initiated XDG shell
fullscreen changes.
Fixes#1995
(cherry picked from commit ddd087d662)
By default, the glfw3native.h header will include the platform-specific
headers necessary for the return types of GLFW native access functions.
Sometimes it is preferrable to declare those types
This commit adds support for the GLFW_NATIVE_INCLUDE_NONE macro, which
when defined disables the inclusion of all platform-specific headers.
Fixes#1348
(cherry picked from commit 05f6c13d11)
GLFW did not restore the previous Xlib error handler when removing its
own, instead resetting to the default handler.
This commit saves and restores the previous error handler.
None of this is thread-safe or could ever be.
Fixes#2108
(cherry picked from commit 26920a1a38)
The joystick code did not distinguish between the allocation status of
the GLFW joystick object and whether it is connection to an OS level
joystick object.
These are now tracked separately.
Fixes#2092
This is adapted to 3.3-stable from
2c204ab52e and
fd7e737216.
The modifier bits for lock keys were only set when the corresponding key
was reported as held down or latched, but not when it was released and
locked.
(cherry picked from commit e9c58bc181)
This avoids glfwCreateWindow emitting GLFW_PLATFORM_ERROR 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.
This is adapted to 3.3-stable from
09653b8c54.
The code assumed that at least some data would be received via the INCR
mechanism and that, as a result, the string buffer would be allocated.
Bug found by Clang static analysis.
(cherry picked from commit 23e6e8e4b7)
This adds support for file path drop events in text/uri-list format.
It is based on work by Pilzschaf in #2040.
Closes#2040
(cherry picked from commit 4cb36872a5)
The code assumed that all data offers were selections that supported
plaintext UTF-8.
The initial data offer events are now handled almost tolerably. Only
selection data offers are used for clipboard string and only if they
provide plaintext UTF-8. Drag and drop data offers are now rejected as
soon as they enter a surface.
Related to #2040
(cherry picked from commit 8d87be1268)
The string pointer used to write the contents of our clipboard data
offer was never updated, causing it to repeat parts of the beginning of
the string until the correct number of bytes had been written.
(cherry picked from commit 4c110bba41)
If data source creation fails, the string containing the data for it
would be freed a second time during termination.
(cherry picked from commit b386371f57)
Passing any part of the result of glfwGetClipboardString to
glfwSetClipboardString would result in, at best, a use-after-free error.
(cherry picked from commit 9c95cfb9f1)
Emitting an error for one specific type of failure in retrieving the
correct name for a display is not very useful, especially when
initialization is otherwise unaffected.
There should be a path for information like that but this isn't it.
Fixes#1791
(cherry picked from commit 955fbd9d26)
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
(cherry picked from commit 07a5518c3e)
The bug described in 03cfe957e7 was
already present for another key where modifiers changes its scancode.
Related to #1993
(cherry picked from commit 8d9231fe5e)
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
(cherry picked from commit 03cfe957e7)
