When using the fallback decorations, GLFW_HOVERED was true also when the
cursor was over one of the window decorations.
This also disentangles the GLFW_HOVERED state from the fallback
decorations. Because GLFW_HOVERED should have had the same behavior as
GLFW_MAIN_WINDOW, the latter has been removed.
We now have three window decoration paths in the Wayland backend:
libdecor decorations, XDG decorations and fallback decorations.
This makes it clearer when code relates to the fallback decoration path,
which should increasingly (hopefully) not get used.
This implements window attention requests via the xdg-activation-v1
protocol.
This was updated by @ elmindreda to work with recent Wayland related
changes to the main branch:
- Switched to current way of handling Wayland protocol files
- Added the xdg-activation-v1.xml protocol file to deps/wayland
- Added missing macros to rename protocol interface globals
The protocol file was copied from wayland-protocols 1.33.
Closes#2287
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.
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 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.
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
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.
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.
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.
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.
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
This moves the X11 polling implementation to a separate file where it
can be used by either the X11 or Wayland backend or both.
This code should be POSIX compatible where necessary but will use the
lower latency but non-standard polling functions ppoll or pollts where
those are available.
This commit is based on work by OlivierSohn and kovidgoyal.
Fixes#1281Closes#1285
The Wayland backend now requires xkbcommon-compose, which was added in
version 0.5.0. xkbcommon 0.5.0 was released in 2014.
This removes the non-composing fallback path for text input.
This adds compile-time support for multiple platforms and runtime
detection of them. Window system related platform functions are now
called from shared code via the function pointer struct _GLFWplatform.
The timer, thread and module loading platform functions are still called
directly by name and the implementation chosen at link-time. These
functions are the same for any backend on a given OS, including the Null
backend.
The platforms are now enabled via CMake dependent options following the
GLFW_BUILD_<platform> pattern instead of a mix of automagic and ad-hoc
option names. There is no longer any option for the Null backend as it
is now always enabled.
Much of the struct stitching work in platform.h was based on an earlier
experimental branch for runtime platform selection by @ronchaine.
Every platform function related to windows, contexts, monitors, input,
event processing and Vulkan have been renamed so that multiple sets of
them can exist without colliding. Calls to these are now routed through
the _glfw.platform struct member. These changes makes up most of this
commit.
For Wayland and X11 the client library loading and display creation is
used to detect a running compositor/server. The XDG_SESSION_TYPE
environment variable is ignored for now, as X11 is still by far the more
complete implementation.
Closes#1655Closes#1958
The Wayland protocol spec[1] states that set_cursor must be called
with the serial number of the enter event. However, GLFW is passing in
the serial number of the latest received event, which does not meet the
protocol spec.
[1] https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_pointer
As a result, set_cursor calls were simply ignored by the compositor.
This fix complies with the protocol more closely by specifically caching
the enter event serial, and using it for all set_cursor calls.
Fixes#1706Closes#1899
The insight to use wayland.xml to resolve the difficult-to-redirect
interface symbols was gleaned from SDL.
Instead of compiling the code output of wayland-scanner separately it is
made part of the wl_init compilation unit. This lets us do things like
transparently rename our copies of Wayland globals.
The OS version of wayland-client-protocol.h is no longer used by GLFW,
but it is presumably ABI compatible with the output of wayland-scanner.
Closes#1174.
Closes#1338.
Related to #1655.
Closes#1943.
Previously, any pointer motion in the window decorations when using the
fallback implementation would obtain the wl_cursor again, and do the
attach danse for no benefit.
This will ultimately allow animated cursors to not reset to the first
frame on motion, once these will be implemented.
The `name` member in the `_GLFWmonitorWayland` struct is used in two places. It is assigned the value from a variable of type `uint32_t` and is compared to another variable of type `uint32_t`, so `name` should also have the same type.
Closes#1569.
This protocol is part of the core Wayland, but it is pretty badly
designed and is missing quite a few features, and is in the process of
being phased out in compositors. Its support in GLFW requires
duplicating pretty much every single window management codepath.
This bumps the required compositor versions to the ones which have
implemented xdg-shell, approximately two years ago, which seems sensible
to me.
