Some clients like X11 LibreOffice clear the selection prior to copying
some content there. This selection clear is correctly seen by our clipboard
manager as a hint to take ownership and preserve the last copied content,
all while LO is issuing other XSetSelection with the new clipboard content.
Our use of META_CURRENT_TIME turns this into a race condition, as there's
both LO and our clipboard manager trying to do XSetSelection(), from our
side it's all up to the order in which the requests arrive to the X server.
In order to break the tie, keep the selection timestamp from the XFixes
event (i.e. the timestamp set by the XSetSelection external call that is
unsetting the clipboard) and ensure it is used for our own XSetSelection
call replacing the selection. In this same situation, it will make the
X server deem the request too old, and let LO win.
If the compositor-side XSetSelection event does not happen in result to
a XFixes selection notify event, the current event time will be used, and
META_CURRENT_TIME as a last resort.
x11: Clear X11 selection source after unsetting owner
The X11 selection source was being preserved after unsetting its
ownership. This is no leak as it would be eventually replaced by
another source, or destroyed on finalize. But it's pointless to
keep it.
wayland: Move the primary data device manager to its own file
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.
wayland: Move MetaWaylandDataOffer to its own file
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.
wayland: Split MetaWaylandDataSource into a separate file
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.
wayland: Rely on MetaSelection::owner-changed for .selection event emission
We already have a signal callback that translates selection ownership changes to
data_device/primary .selection events. Given both will be run when a data source
is being replaced, and this event emission being deleted is kinda short sighted
in that in only knows about Wayland, rely entirely on MetaSelection::owner-changed
emission.
Fixes spurious .selection(null) events being sent when a compositor-local source
takes over the selection without the focus changing (eg. screenshot to clipboard).
wayland: Do not cancel old data source when setting new selection
This is taken care already by the MetaSelection machinery, by
deactivating the previous selection source when setting a new one.
That works across X11 and internal selection sources. This
only works when replacing one wayland source with another, and
actually results in doubly .cancelled events due to the other
paths.
