The protocol as-is doesn't allow clients to mutate wl_buffers.
Let's make it clear that wl_buffer.release is not used for that
purpose. Buffer re-use can be added in a future protocol version
if desirable.
Add a small note to explain that no wl_buffer mutation implies no
wl_shm_pool's backing storage mutation as well.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/201
It wasn't clear that it's important clients set up their initial
xdg_surface state before they send the initial commit. This is
required for the compositor to be able to send a proper configure
event depending on size constraints and any policies it might want
to apply (e.g. specific app ID always shows up in a designated
workspace).
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Signed-off-by: Simon Ser <contact@emersion.fr>
Co-authored-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Simon Zeni <simon@bl4ckb0ne.ca>
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Signed-off-by: Simon Ser <contact@emersion.fr>
Co-authored-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Simon Zeni <simon@bl4ckb0ne.ca>
GitLab understands the "Draft:" prefix and will mark the MR
accordingly. GitLab used to understand the "WIP:" prefix, but
that's no longer the case.
Signed-off-by: Simon Ser <contact@emersion.fr>
This protocol allows clients to set icons for their toplevel windows.
Icons can be loaded from the XDG icon stock using their name, or can
alternatively be provided by the client as wl_shm-backed wl_buffer.
A toplevel icon represents the individual toplevel (unlike the
application or launcher icon, which represents the application as a
whole), and may be shown in window switchers, window overviews and
taskbars that list individual windows.
Resolves: #52
Signed-off-by: Matthias Klumpp <matthias@tenstral.net>
There's no protocol error for making requests on the object after the wl_surface
has been destroyed, so the object has to become inert in that case.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
Currently our CI setup has a downside: for each push on a merge
request, two pipelines are triggered. The first is triggered in
the context of the forked repository, and the second is triggered
in the context of the MR in the parent repository.
Replace the workflow rules with the ones in the official docs [1],
so that a branch pipeline isn't triggered when a MR exists for that
branch.
[1]: https://docs.gitlab.com/ee/ci/yaml/workflow.html#switch-between-branch-pipelines-and-merge-request-pipelines
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: fbf7fc3517 ("ci: use detached CI pipelines")
The strict "mailbox" model of wayland past is not how modern compositors
process commits, and many explanations of how double buffered state is
applied throughout wayland-protocols are no longer strictly accurate.
Instead of trying to define double-buffered state at every point of use,
just reference the evolving definition of wl_surface.commit.
This still leaves a few old definitions that weren't trivially updated.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This protocol extension has not changed in a long time, is
widely supported, and no upcoming breaking changes are planned.
The interface names are left unchanged, so that compositors and
clients don't need to be updated. In particular, the legacy "z"
prefix is still part of the interface name.
Signed-off-by: Simon Ser <contact@emersion.fr>
This protocol allows clients to set an alpha multiplier for the whole surface,
which allows it to offload alpha changes for the whole surface to the compositor,
which in turn can offload them to KMS.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
Port the changes made in 31236887df ("xdg-shell: move maximized
state definition together") to the various tiled states.
Signed-off-by: Simon Ser <contact@emersion.fr>
This simple protocol definition allows clients to express a "dialog"
relationship of a toplevel with its parent and extend the possible
hints. This allows compositors to attach certain behavior according
to these hints.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com>
libinput may not always have a descriptive name for a tablet
device, in which case it's better to let the Wayland client
pick a fallback (potentially localized) than send a fake string.
Not all tablet devices are USB, so make it clear that the id
event may be skipped.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/180
This protocol allows applications to request that a window is moved
at the same time as a drag operation - effectively dragging windows.
With this features such as detaching a tab from a window and reattaching
it, dragging tabs between windows or (un)dockable tool windows can
be implemented.
Based on the previously proposed extended drag protocol but trimmed
down.
Signed-off-by: David Redondo <kde@david-redondo.de>
xdg-shell assumes that the client provides all parts of a toplevel
window, i.e. things like titlebar, drop shadow. There are already things
here and there implies it, but it could be helpful to spell it out.
This doesn't change any semantics - it's still valid, from the
perspective of the protocol, to create a toplevel without any
decorations, and it always has been, it just means that the semantical
intention is for them to be exactly so.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
wayland-protocols is more than just a repository of XML files.
Make this clear and link to the governance document and member
list.
Signed-off-by: Simon Ser <contact@emersion.fr>
Specifically this also changes the well-known name for flatpak from
"flatpak" to "org.flatpak". This would be a breaking change but there is
no released version of flatpak yet with security-context support.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
"ask the client" isn't very clear. Let's use the word "configure"
which is more explicit: the client doesn't have a say in this.
(Note, wording in the following paragraphs is clearer and uses the
word "must".)
Signed-off-by: Simon Ser <contact@emersion.fr>
