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)
The use of this extension is required to enable the MoltenVK physical
device as of Vulkan SDK 1.3.216.0. This is because MoltenVK is still
very (very) slightly non-conformant.
This was adapted to 3.3-stable from
3b3d58df47 and
84e165ef64.
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)
