Commit Graph

14 Commits

Author SHA1 Message Date
Carlos Garnacho
9b26694bbc wayland: Implement DnD actions as per wl_data_device v3 changes
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
2016-01-19 13:55:33 +01:00
Carlos Garnacho
da0aac665f xwayland: Protect against crash on x11->wayland transfer cancellation
If the transfer is cancelled, the X11SelectionData will be cleared from
the MetaSelectionBridge, although x11_data_write_cb() was invariably
expecting it to be non-NULL.

If the write was cancelled, all the actions done in x11_data_write_cb()
are moot, so just return early. If there's other errors happening
(eg. "connection closed" if the target client happens to crash), we
should still attempt at clearing the data anyway.

https://bugzilla.gnome.org/show_bug.cgi?id=754357
2015-10-02 12:21:17 +02:00
Carlos Garnacho
6f64d6b0aa wayland: Check the drag focus before processing XDND dest-side messages
If the drag dest surface suddenly disappears, we may find ourselves
processing an XdndPosition message that was sent before the X11 drag
source had an opportunity to find out.

In that case mutter does know, so double check before processing the
messages.
2015-09-28 16:22:54 +02:00
Carlos Garnacho
ebeca983c7 wayland: Improve transformation of the UTF8_STRING atom to mimetype
We try to translate the atom with its corresponding mimetype both back
and forth, which actually breaks if the X11 client chose to announce the
mimetype atom. To do the translation properly, keep track on whether the
source announced the UTF8_STRING atom, and reply back with this only if
that happened.
2015-09-28 16:22:43 +02:00
Florian Müllner
bc00f118f3 Avoid shadowing existing variables 2015-09-24 03:08:22 +02:00
Florian Müllner
27b37407d0 Don't duplicate declarations from G_DEFINE_TYPE 2015-09-24 03:01:51 +02:00
Javier Jardón
6ea7fa9973 xwayland: Add missing include
https://bugzilla.gnome.org/show_bug.cgi?id=754621
2015-09-07 14:13:48 +01:00
Jonas Ådahl
5547c98f97 wayland: Make MetaWaylandDataSource ownership protocol specific
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
2015-06-30 11:23:40 +08:00
Carlos Garnacho
4a968c3b4e xwayland: Implement X11-to-wayland DnD
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
2015-05-29 11:27:53 +02:00
Carlos Garnacho
ccb7833e99 xwayland: Implement wayland-to-X11 DnD
X11 client windows now hook a X11-specific MetaWaylandDragDestFuncs
that converts these into Xdnd* messages, and an additional selection
bridge has been added to take care of XdndSelection, and the data
transfers done through it.

https://bugzilla.gnome.org/show_bug.cgi?id=738312
2015-05-29 11:27:53 +02:00
Carlos Garnacho
b449ba942a xwayland: Refactor XFixesSelectionNotifyEvent handler
Prepare it for more selection atoms (i.e. XdndSelection) to come.

https://bugzilla.gnome.org/show_bug.cgi?id=738312
2015-05-29 11:27:53 +02:00
Carlos Garnacho
0b0ce4193f xwayland: Ensure we've got an owner when setting the X selection owner
Otherwise we may end up claiming the X selection when there's no wayland
selection owner.
2015-05-18 20:59:07 +02:00
Carlos Garnacho
719d8bd0c7 xwayland: remove unused struct field 2015-05-18 20:58:57 +02:00
Carlos Garnacho
4fc1811c15 wayland: Add X11/wayland selection interoperation
This piece of code hooks in both wl_data_device and the relevant X
selection events, an X11 Window is set up so it can act as the clipboard
owner when any wayland client owns the selection, reacting to
SelectionRequest events, and returning the data from the wayland client
FD to any X11 requestor through X properties.

In the opposite direction, SelectionNotify messages are received,
which results in the property contents being converted then written
into the wayland requestor's FD.

This code also takes care of the handling incremental transfers through
the INCR property type, reading/writing data chunk by chunk.

https://bugzilla.gnome.org/show_bug.cgi?id=738312
2015-05-15 17:43:53 +02:00