protocol: Make DnD pointer cursor updates responsibility of compositors

Originally, having the drag source client in charge of cursor updates
was simple enough, flexible and coherent with the prior art.

Things accumulated over time that made it not such a great choice:

- The tablet protocol sporting its own on-screen pointer cursors
  made clients need to be painfully aware of the device that started
  drag-and-drop, in order to modify the correct cursor, provide the
  correct serials, etc.
- The shapes protocol greatly simplified the set of sensible cursors
- On top of that, not every compositor nor toolkit library knows
  to do well all of that.

Nowadays, it seems simpler to leave this bit of user feedback up
to the compositor, as it will/should be aware of the device driving
drag-and-drop, as well as the currently selected action.

In order to allow for a seamless transition (mostly in the client
side), document this as mandatory only if version 4 of the
wl_data_* interfaces is implemented by the compositor. The version
bump only identifies to clients the possibility to avoid doing
any cursor feedback themselves.

Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
This commit is contained in:
Carlos Garnacho 2025-04-07 13:20:28 +02:00
parent 6137c8c213
commit 33be03451a

View file

@ -518,7 +518,7 @@
</event>
</interface>
<interface name="wl_data_offer" version="3">
<interface name="wl_data_offer" version="4">
<description summary="offer to transfer data">
A wl_data_offer represents a piece of data offered for transfer
by another client (the source client). It is used by the
@ -711,7 +711,7 @@
</event>
</interface>
<interface name="wl_data_source" version="3">
<interface name="wl_data_source" version="4">
<description summary="offer to transfer data">
The wl_data_source object is the source side of a wl_data_offer.
It is created by the source client in a data transfer and
@ -858,15 +858,19 @@
into a "move" operation), so the effects of the final action must
always be applied in wl_data_offer.dnd_finished.
Clients can trigger cursor surface changes from this point, so
they reflect the current action.
Compositors should trigger cursor surface changes based on the
currently active action. This behavior is mandatory with the version 4
of the wl_data_device_manager interface, and optional before that.
Prior to version 3, the client holding the current wl_data_source
may trigger these cursor updates.
</description>
<arg name="dnd_action" type="uint" summary="action selected by the compositor"
enum="wl_data_device_manager.dnd_action"/>
</event>
</interface>
<interface name="wl_data_device" version="3">
<interface name="wl_data_device" version="4">
<description summary="data transfer device">
There is one wl_data_device per seat which can be obtained
from the global wl_data_device_manager singleton.
@ -1027,7 +1031,7 @@
</request>
</interface>
<interface name="wl_data_device_manager" version="3">
<interface name="wl_data_device_manager" version="4">
<description summary="data transfer interface">
The wl_data_device_manager is a singleton global object that
provides access to inter-client data transfer mechanisms such as