According to both Apple and LunarG, a private copy of the macOS Vulkan
loader libvulkan.1.dylib should be placed in the Frameworks directory
of the bundle and not its main executable directory.
This commit updates the dynamic loading path accordingly.
Fixes#2113Closes#2120
(cherry picked from commit 9b7713cf92)
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)
If a fullscreen window with GLFW_DECORATED set had its XDG decorations
changed to client mode by the compositor, it would seemingly receive
GLFW fallback decorations as if it was windowed mode.
This is possibly related to #2001.
(cherry picked from commit da6713cd09)
This moves what is effectively showing the window to where that is done
on other platforms, i.e. last in the platform CreateWindow function.
(cherry picked from commit 74b4ceb835)
The logic that checks the decorated attribute belongs on the outside
along with other related checks (fullscreen, monitor, decoration mode).
(cherry picked from commit c4fbe80d90)
Note that the handling of configure events, acks and commits is still
not ideal. This is just a small step in, hopefully, a good direction.
Fullscreen toggling via glfwSetWindowMonitor now works on Weston, but
mostly incidentally.
(cherry picked from commit be7f4513c0)
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)
If the xdg_toplevel has a decoration, we need to wait for its first
configure event as well before we are allowed to attach the first
buffer.
It seems racy to assume that this will always happen inside the first
surface configure sequence, so this commit makes that condition
explicit. This may turn out to have been overly defensive.
(cherry picked from commit 3203599cac)
Refer to the XDG decoration mode (or the lack of one) directly instead
of setting a boolean in a struct meant for the fallback decorations.
This makes things a bit more verbose but is in preparation for
a refactoring of all decoration paths.
(cherry picked from commit 2df0ce07fa)
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)
Window iconfication and maximization events were being emitted before
xdg_surface::configure, making it possible for user code to indirectly
commit surface changes from those event callbacks before
xdg_surface::ack_configure.
This postpones those events until after the ack has been sent.
(cherry picked from commit 85f5a51912)
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)
The surface was resized and the size event was emitted before we had
sent xdg_surface::ack_configure. If user code then called some GLFW
function that commited the surface, those changes would all get applied
to the wrong configure event.
This postpones size changes until after the ack.
(cherry picked from commit e33db6d7aa)
The wayland-scanner output provides really nice, self-documenting
version macros, so we should use them whenever possible.
(cherry picked from commit ed39ff43f9)
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)
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)
The clipboard string should not be freed on SelectionClear. The user
may have received it from glfwGetClipboardString and it should remain
valid until the next call to a public clipboard string function.
(cherry picked from commit f60547ac80)
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 Wayland backend was the only one where half the window and input
related code was in the init module. As those bits want to share more
utility code with the window module, the interface between them grows.
To prevent that, this gathers nearly all window and input related code
into the window module.
This is adapted to 3.3-stable from
b7a3af9b79.
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)
There were no checks for invalid values or asserts for all invalid NULL
pointers to glfwSetWindowIcon or glfwCreateCursor.
Fixes#1862
(cherry picked from commit 66a4882eb1)
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)
