It makes little sense to have a catch-all grab vaildation function,
considering that e.g. tablet tool implicit grabs are possible as well.
Besides, the function has always returned true anyway.
This increases type safety, makes it more obvious that role_data
must represent the role object, and will allow for automatic
cleanup when the resource is destroyed.
According to the protocol text, the popup will be immediately dismissed
when the grab is rejected. Because the grab can't be executed with a
destroyed seat, the popup is dismissed when one is provided.
When a client attaches a NULL buffer to its wl_surface, it's
unmapped. This resets the xdg_surface in its initial state. An
extra NULL commit makes the compositor send an initial configure
event.
Note, wlr_xdg_toplevel.added is separate from wlr_xdg_surface.added.
Closes: https://github.com/swaywm/sway/issues/7397
This allows whatever the user calls from the signal handlers to react to observe
the new state rather than the old, e.g. that a surface is no longer mapped in
the unmap handler.
With protocol additions such as [1], compositors currently have no
way to opt out of the version upgrade. The protocol upgrade will
always be backwards-compatible but may require new compositor
features.
The status quo doesn't make it possible to ship a protocol addition
without breaking the wlroots API. This will be an issue for API
stabilization [2].
To address this, let compositors provide a maximum version in the
function creating the global. We need to support all previous versions
of the interface anyways because of older clients.
This mechanism works the same way as Wayland clients passing a version
in wl_global.bind.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3514
[2]: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1008
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3397