exo: Add extended-drag extension and its stub implementation
TL;DR: Wayland Protocol needs to be extended to make it possible to properly support full Chromium's tab dragging experience. Further details in the Design document [1]. This is the first of a patch series which implements extended-drag extension in Exo compositor, adding the protocol descriptor XML file, boilerplate code as well as a stub implementation of it. Follow-up CLs will incrementally implement the extension features and start using it in Chromium Ozone/Wayland (client-side). ----------------------------------------------------------------------- An overview of how this protocol is aimed to be used in a tabdrag-like scenario, but in generic terms, is outlined below: 1. An UI item (eg: a tab in a tab bar) starts to be dragged within shell surface A owned by source client S. At some point, it gets far enough from its original location and S then starts a Wayland "extended drag" session, which protocol-wise requires to: 1.1. Create a wl_data_source, set one (or more) mime type and the supported dnd actions; 1.2. Create a zcr_extended_drag_source for the newly created drag source. Here it is possible to set a few options, such as: - ALLOW_SWALLOW: determines that the dragged item can be attached (or incorporated, also referred to as "swallow" in this protocol) to another surface, including use cases such as Chrome's tab drag. - ALLOW_DROP_NO_TARGET: In the standard DND protocol, dropping something outside shell surfaces lead to a wl_data_source::cancel, which is problematic in use cases such as tab drag, preventing us from detecting when it was really cancelled, e.g: ESC pressed. - LOCK_CURSOR: Keep the cursor shape unchanged during the whole session. Ultimately, having an extended drag source attached to the wl_data_source used to wl_data_device::start_drag instructs the compositor to run the drag session in the "extended mode". 1.3 Start the drag session as usual (i.e: wl_data_source::start_drag), with a null drag icon surface. Assuming that we're still in attached mode for now. In addition, from now on, client S must start watching for wl_data_device::{enter,leave,motion} events in order to be able to detect the next actions and state transitions as the user drags the UI item around. 1.4 Store the (x_offset, y_offset) location where the drag started in S and keep them synced to the values received in wl_data_device::motion() events. 2. Once the drag gets far enough from the original UI item's container (ie: tab bar), it's time to detach (or unswallow) it from surface A. To achieve it, client S must: 2.1. Create a new wl_surface B + its corresponding shell surface, e.g: a toplevel xdg surface where a new detached browser window will rendered to in Chrome's tab drag use case; 2.2. Issue a zcr_extended_drag_source::drag(B, x_offset, y_offset) request, which tells the compositor (in advance) that B must be set as the extended-drag surface, using x and y offsets to translate it from the current pointer location; 2.3. Map surface B (configure, attach buffer, etc) as usual. After this B's shell surface should show up tied to the mouse pointer and the compositor is supposed to take care of it, putting it in a special state where, for example, it does not receive events, etc, acting just like a standard DND "drag icon". At this point, the "unswallow" operation is done and the extended-drag session enters in detached state. 3. Supposing the drop happens while in detached state, there are 2 possible flows, which depend on whether ALLOW_DROP_NO_TARGET config is set or not (see 1.2). If it is set, wl_data_source::dnd_finished event is sent to the source client S, otherwise wl_data_source::cancelled is sent. 4. Otherwise, if before dropping, the pointer enters surface C, owned by client T. T receives a wl_data_offer O through wl_data_device::offer event as usual, to which it can attach a zcr_extended_drag_offer XO to it by issuing zcr_extended_drag::get_extended_drag_offer(O). Target client T, then starts monitoring wl_data_device::motion events, so that it can trigger a swallow based on where the pointer is. If B is dragged over a region that leads to a swallow, T must: 4.1 Issue a zcr_extended_drag_offer::swallow(serial, mime) request, asking source client S to incorporate the dragged item into its UI. S then receives a zcr_extended_drag_source::swallow(mime) event and it can accept it by calling zcr_extended_drag_source::drag(null, 0, 0), so client T can finally render it as part of its UI. At this point, the session is back to a state similar to 1.4. So, similarly to 2, once the drag gets far enough, T might want to unswallow (aka: detach) the UI item. In order to do so it must: 4.1.1 Call unswallow(serial, mime, x_offset, y_offset) on the extended-drag offer XO (created at step 4), whereas the offsets tell how the dragged surface must be positioned related to the pointer location. Client S will then receive a zcr_extended_drag_source::unswallow(mime, x_offset, y_offset) event so that it can create and map a new surface D and issue a zcr_extended_drag_source::drag(D, x_offset, y_offset), same as in step 2.3, making surface D to show up under the pointer. At target side, T can then re-render its UI without the dragged item. This finishes the unswallow (or detaching) operation, transitioning the session back to "detached" state. [1] https://docs.google.com/document/d/1s6OwTi_WC-pS21WLGQYI39yw2m42ZlVolUXBclljXB4/edit?usp=sharing Bug: 1099418 Change-Id: I8d876e96e45717c625c1d1bdcc269b100524cbc7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2307653 Commit-Queue: Nick Yamane <nickdiego@igalia.com> Reviewed-by:Mitsuru Oshima <oshima@chromium.org> Cr-Commit-Position: refs/heads/master@{#811055}
Showing
This diff is collapsed.
Please register or sign in to comment