This brings the latest released versions of all used Wayland protocol
files into this repository, removing the need for the user to arrange
a sufficiently new version of wayland-protocols.
The wayland.xml protocol file was copied from wayland 1.22.0.
The additional protocol files were copied from wayland-protocols 1.32.
Because of how files are moved and renamed inside the wayland-protocols
repository, it will not always be possible to update all our protocol
files from a single release without also potentially updating related
code (acceptable) and prematurely breaking compatibility with
compositors that still only support an earlier incompatible version
(unacceptable).
The macro in src/CMakeLists.txt has been modified to hopefully make it
easier to add new protocol files. This made it necessary to change the
name of a few of the generated header files.
Closes#2053
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.
A GLFW_CURSOR_UNAVAILABLE error would be emitted each time the cursor
moved over the fallback decorations if the standard cursor shape
appropriate for that part was missing on the system.
These errors served no useful purpose and have been removed.
This is partly based on the implementation of libdecor support in
PR #1693 by @ christianrauch.
Where available, the libdecor library is loaded at init and becomes the
preferred method for window decorations. On compositors that support
XDG decorations, libdecor in turn uses those. If not, libdecor has
a plug-in archtecture and may load additional libraries to either use
compositor-specific decorations or draw its own.
If necessary, support for libdecor can be disabled with the
GLFW_WAYLAND_LIBDECOR init hint. This is mostly in case some part of
the dynamic loading or duplication of header material added here turns
out to cause problems with future versions of libdecor-0.so.0.
Fixes#1639Closes#1693
Related to #1725
This commit simplifies the detection of which element of a fallback
decorated window the pointer has entered. Instead of looping through
the list of windows, the user pointer of fallback decoration surfaces is
set to the GLFW window object.
This replaces (one case of) manual management of weak links between
windows and monitors, both objects with complex life times, with
wl_object pointers used as opaque key values.
This is in preparation for adding support for libdecor, which creates
its own proxies on our display. It will likely also be helpful to some
people using native access on Wayland.
This is partly based on the implementation of libdecor support in
PR #1693 by @ christianrauch.
If a window was initially fullscreen then it would not get an XDG
decoration object. If the window was later switched to windowed mode it
would then get fallback decorations instead of XDG ones.
This adds a window hint string for the xdg_toplevel::app_id, which is
used by desktop environments to connect windows with application icons
and other information. This is similar to the WM_CLASS property on X11.
A few very minor fixes were done by @elmindreda during merge.
Fixes#2121Closes#2122
If the key or character callback performs actions that indirectly
updates the key repeat timer, those changes would be undone once the key
callback returned.
This fixes the order of operations so that key repeat is fully set up
before the key related events are emitted.
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.
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.
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.
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.
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
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.
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.
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.
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.
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
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
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.
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.
These changes make GLFW fullscreen more consistent, but unfortunately
also make GLFW even more oblivious to user-initiated XDG shell
fullscreen changes.
Fixes#1995
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.
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.
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.
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
