From 33be03451a754019721858c701b99065fa1a2345 Mon Sep 17 00:00:00 2001 From: Carlos Garnacho Date: Mon, 7 Apr 2025 13:20:28 +0200 Subject: [PATCH] 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 --- protocol/wayland.xml | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 1af51d36..e3b5b3b4 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -518,7 +518,7 @@ - + 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 @@ - + 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. - + There is one wl_data_device per seat which can be obtained from the global wl_data_device_manager singleton. @@ -1027,7 +1031,7 @@ - + The wl_data_device_manager is a singleton global object that provides access to inter-client data transfer mechanisms such as