- Event stream adaptations. When there is a toplevel-drag in place, do:
- Send wl_data_source.dnd_finished and end the session successfully
- Send wl_data_source.cancelled and end the MetaWindowDrag when ESC key
is pressed.
- Modify MetaWaylandDataDevice such that, when a toplevel-drag is
running, it does:
- Propagate motion events, so that they can be processed further by
MetaWindowDrag.
- Ends the associated MetaWindowDrag upon release event.
- Hook up the window mapping process in MetaWindowWayand, such that:
- the initial position of the window attached to the ongoing
toplevel-drag instance can be calculated and set.
- the appropriate gravity and flags can be set when calling MetaWindow's
meta_window_move_resize_internal, which allows it for example to be
moved freely (unconstrained) as per current dragging cursor.
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
- [x] Disable visibility change animations
- [x] Dnd events stream adaptations
Signed-off-by: Nick Diego Yamane <nickdiego@igalia.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4107>
- 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>
Replace the sync_focus() calls with a set_focus() do-it function taking
a surface. This is in line with the rest of the things that happen at
the default MetaWaylandEventInterface.focus implementation, and will
make these correctly observe the presence of grabs, since
meta_wayland_seat_get_input_focus() will return the would-be focus
in these cases.
This change makes the "focused" client selection truly
in sync with the keyboard focus.
Fixes: 5ca10c31d1 ("wayland: Follow seat's input focus client for clipboard selections")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3490
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3789>
While every kind of input is seen as coming from the Virtual
Core Pointer in the X11 case, we can largely abstract away from
that fact, and lock XDnD pointer input to the most plausible
source (e.g. a device with a pressed button), instead of only
working with pointer input.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
This collection of event handlers is the most special of them all, as
they want to unset any pointer/touch/stylus/keyboard/pad/etc focus,
and handle events from a selected device/sequence combination through
the MetaWaylandDragDest interfaces.
The same interfaces also replace the MetaWaylandKeyboardGrabInterface
in effect that handled DnD action changes.
On the XDnD special grab side, we mainly need to let the current
client (i.e. the drag source) keep receiving input events, as they
drive the DnD operation from the X11 realm.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
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>
Since the introduction of ClutterGrabs, MetaDnd now no longer gets
notified about input events on the stage during grabs (for example while
the alt-tab popup is shown) and thus can't move the grab feedback actor
anymore.
To fix this, forward events to MetaDnD directly from
meta_display_handle_event() when a ClutterGrab is in effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2308>
Instead of having everything clumped at MetaWaylandDataManager,
split the primary selection to its own struct. This manager is
handled separately from wl_data_device_manager and other selection
managers, so they would be able to interoperate between them, even.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
This is still an openly defined struct, as we will need accessed
by "subclasses". Same principle applies than with the
MetaWaylandDataSource refactor, this is not meant to introduce
functional changes, so just go with it.
On the bright side, the interactions are now clearer, so it could
be made saner in the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
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
In XDND, we just get a hint on XdndPosition about what's the action
chosen by the user. Make the data source actions the full set on
XdndEnter (as we can't know better), and pass the hint in XdndPosition
as the user chosen action as it should be.
Makes Wayland drop sites aware of the user action as per XDND with X11
drag sources, and still makes modifiers during DnD work.
https://gitlab.gnome.org/GNOME/mutter/issues/974https://gitlab.gnome.org/GNOME/mutter/merge_requests/1005
Those were used to signal clipboard ownership around, but that got
replaced by MetaSelection and friends. These signals are no longer
listened on, so can be safely removed.
https://gitlab.gnome.org/GNOME/mutter/issues/591
Instead of taking resource and send/cancel funcs, take a
MetaWaylandDataSource, which exposes all the vfuncs to do the same on the
internal resource.
This has the added side effect that only MetaWaylandDataSource has a
pointer to the wl_resource, which may be unset untimely.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/842
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
No XDnD events which notify DnD status change comes in Wayland. To emulate XDnD
behavior, MetaDnd checks whether there is a grab or not when the modal window
starts showing. When there is a grab, it processes the raw events from
compositor, and emits DnD signals for plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=765003
Add an additional MetaWaylandDataSource implementation for primary selection
sources, and methods to set primary selection offers. Primary selection
sets altogether a different channel than the clipboard selection, those don't
cross in any way.
Also, the bridge for the X11 PRIMARY selection atom has been added, which
adds all the necessary handling to translate primary selection both ways
with wayland and X11 applications.
https://bugzilla.gnome.org/show_bug.cgi?id=762560
Since we are using the surface actor to draw the DND icon, the offset
is already accounted for by MetaSurfaceActorWayland, and passing the
surface position offset would effectively double the actual offset,
causing the icon to be misplaced.
This patch always sets the anchor offset to (0, 0) when the icon is a
Wayland surface, and lets the surface actor deal with the offsetting.
https://bugzilla.gnome.org/show_bug.cgi?id=759222
We now additionally send:
- wl_data_offer.source_actions
- wl_data_source.action
- wl_data_offer.action
- wl_data_source.dnd_drop_performed
- wl_data_source.dnd_finished
The protocol changes allow for compositors to implement different policies
when chosing the action, mutter uses this to reimplement the same behavior
that GTK+ traditionally had:
- Alt/Control/Shift modifiers change the chosen action to
ask/copy/move respectively
- Drags with middle button start out as "ask" by default
As mutter now also grabs the keyboard and unsets the window focus for these
purposes, the window focus is restored after the drag operation has
finished.
The Xdnd bridge code is also modified to cope with actions, so mixed
wayland-x11 scenarios are able to convey that information.
https://bugzilla.gnome.org/show_bug.cgi?id=760805
Each keyboard focus change ends up calling the MetaWaylandDataDevice
counterpart, we don't need though to notify the current selection
again. In order to fix this, keep track of the current client, and
only emit the relevant signals when the focus switches to another
client.
The situations where wl_data_device.selection were emitted during
focus changes between surfaces of the same client was inocuous most
of the times, although it's prone to inducing confusing behavior
on context menu clipboard actions, as the closing menu triggers a
focus change, which triggers a whole new wl_data_offer being created
and given on wl_data_device.selection, at a time where there's already
ongoing requests on the previous data offer.
https://bugzilla.gnome.org/show_bug.cgi?id=754357
Firstly, this patch makes MetawaylandDataSource a GObject. This is in
order to easier track its lifetime without adding destroy signals etc. It
also makes the vfunc table GObject class functions instead while at it,
as well as moves protocol specific part of the source into their own
implementations.
An important part of this patch is the change of ownership. Prior to this
patch, MetaWaylandDataDevice would kind of own the source, but for
Wayland sources it would remove it if the corresponding wl_resource was
destroyed. For XWayland clients it would own it completely, and only
remove it if the source was replaced.
This patch changes so that the protocol implementation owns the source.
For Wayland sources, the wl_resource owns the source, and the
MetaWaylandDataDevice sets a weak reference (so in other words, no
semantical changes really). For XWayland sources, the source is owned by
the selection bridge, and not removed until replaced or if the client
goes away.
Given the changes in ownership, data offers may now properly track the
lifetime of a source it represents. Prior to this patch, if an offer with
an XWayland source would loose its source, it wouldn't get notified and
have an invalid pointer it would potentally crash on. For Wayland
sources, an offer would have a weak reference and clean itself up if the
source went away. This patch changes so the behavior is consistent,
meaning a weak reference is added to the source GObject so that the offer
can behave correctly both for Wayland sources and XWayland sources.
https://bugzilla.gnome.org/show_bug.cgi?id=750680
When DnD is started from an X11 client, mutter now sets up an special
grab that 1) Ensures the drag source keeps receiving events, and 2)
Moves an internal X Window over wayland clients as soon as the pointer
enters over these.
That window will act as the X-side peer for the currently focused
wayland client, and will transform XdndEnter/Position/Leave/Drop
messages into wayland actions. If DnD happens between X11 clients,
the window will be moved away and unmapped, to let these operate as
usual.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
This will be useful in order to interact with drag dest surfaces in
its windowing-specific ways, although everything defaults to the
wayland vfuncs.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
Expose it partly (in internal headers anyway), and pass a vtable for the
data source functions, the wayland vfuncs just delegate operations on the
wl_data_source resource. The resource has been also made optional, although
it'll be present on all data sources from wayland clients.
The ownership/lifetime of the DnD data source has also changed a bit,
belonging now to the MetaWaylandDataDevice like the selection one does, as
we can't guarantee how long it will be needed after the grab is finished,
it will be left inert and replaced the next time DnD is started at worst.
This allows the creation of custom/proxy data sources, which will turn out
useful for X11 selection interoperation.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
This copies the basic input support from the Clayland demo compositor.
It adds a basic wl_seat implementation which can convert Clutter mouse
events to Wayland events. For this to work all of the wayland surface
actors need to be made reactive.
The wayland keyboard input focus surface is updated whenever Mutter
sees a FocusIn event so that it will stay in synch with whatever
surface Mutter wants as the focus. Wayland surfaces don't get this
event so for now it will just give them focus whenever they are
clicked as a hack to test the code.
Authored-by: Neil Roberts <neil@linux.intel.com>
Authored-by: Giovanni Campagna <gcampagna@src.gnome.org>
