- For already mapped windows, the window drag session is started
straight away;
- For about-to-be-mapped window (ie: undocking window use case):
- The "shown" signal for the dragged window triggers the actual
MetaWindowDrag once it's mapped.
- MetaWindowWayland now handles the case of toplevel-drag and position
the window about to be mapped according to the toplevel-drag
parameters.
- While attached to a toplevel-drag, the window state is updated to:
- Actor's "reactive" state is set to false, which in practice excludes
it from the possible drag target list;
- WindowActor's "tied to drag" state is set to true, which results in
initial placement constraints to be skipped, so newly created
(detached) windows can be freely dragged around.
- Toplevel drag session ends upon:
- dnd drop and cancellation.
- xdg_toplevel_drag_v1 object destruction (client-side).
- data source destruction.
Status:
- [x] Basic window drag triggering
- [x] Exclude the dragged window from event targets
- [x] Event forwarding (window drag vs wayland grabs)
- [x] Offset calc relative to toplevel geometry
- [x] Attach already mapped windows
- [x] Properly support not-yet-mapped windows
- [ ] Disable visibility change animations
- [ ] Dnd events stream adaptations
Signed-off-by: Nick Diego Yamane <nickdiego@igalia.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4107>
create_and_send_dnd_offer() sets the compositor of the offer to the one
from the MetaWaylandDataSource. This then later gets used in
display_from_offer() when trying to get the context from the compositor.
meta_wayland_data_source_xwayland_new() however was not setting the
compositor, so this was causing crashes when dragging things from X11
windows on Wayland.
Fixes: 2731f0cda ("wayland: Setup and use ownership chains")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2723
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2956>
As elsewhere, make sure objects that need to have a ownership up to the
context, and use this ownership chain to find relevant components, such
as the backend or the Wayland compositor object instance.
wayland/data-device: Hook up data devices to seats
They are tied to a seat - make that connection in struct fields too, so
that related objects can get to the context via it.
wayland: Don't get Wayland compositor via singleton getter
This means via the ownership chain or equivalent.
xwayland: Hook up manager to Wayland compositor
Same applies to the drag-n-drop struct.
xwayland: Make X11 event handling compositor instance aware
This avoids finding it via singletons in the callee.
xwayland: Don't get Wayland compositor from singleton
xwayland: Pass manager when handling dnd event
window/xwayland: Don't get Wayland compositor from singleton
xwayland/grab-keyboard: Don't get backend from singleton
xwayland: Don't get backend from singleton
wayland: Always get the backend from the context
This means traveling up the ownership chain or equivalent when
necessary.
wayland: Hook up data devices, offers and sources to the compositor
This allows tying them to a context without going through any
singletons.
wayland: Don't get display from singleton
xwayland: Don't get display from singleton
tablet: Don't get display from singleton
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
The split wasn't 100% clean, and some extra private API had to be
added for it (but well, looking at the API, it's already evident
there's a cleanup/streamlining task due). This is meant to be a
refactor with no functional changes, so just go with it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
