Summary:
Clipboard managers and middle click paste are new protocols.
We want to be able to copy from a clipboard manager to a regular
clipboard and vice versa without duplicating loads of code.
If we support kliper's "syncronise contents of the clipboard and
selection" inside the compositor that would become an unmanageable amount
of combinations.
It also potentially allows the idea of our XWayland bridge not being a
wayland client and simplifying that code.
Test Plan: Unit test passes
Reviewers: #kwin
Subscribers: zzag
Differential Revision: https://phabricator.kde.org/D29329
Summary:
A DataDevice will have zero or one active DataSource as the seclection.
In the existing code we track the current data device then update it to
the newest data device
when the source inside a data device changes.
If we store the active data source inside Seat instead of the device
everything becomes
somewhat simpler and safer.
An entire unit test vanishes as that case of an externally set
DataDevice with no source
can no longer happen.
There's also a lot of duplication that's been merged in this patch so we
have one path.
There are some technical behavioural changes in particular we do cleanup
when the
source vanishes rather than the data device, but if anything that seems
safer and more correct.
It's a precursor for introducing an abstraction class round the source
without needing to meddle
with too much code.
Test Plan: Relevant unit tests passed, ran with it for a while with no
issue.
Reviewers: #kwin
Differential Revision: https://phabricator.kde.org/D29328
Summary:
Some of the documentation did not say what the purpose of the
respective class was, but rather gave a tautology.
For people new to the code base it helps to mention that
DPMS is power management.
That DataDevice is for copy-and-paste and drag-and-drop is
maybe obvious to people used to X11 API, but not very clear
to most others.
When first reading the KWayland code, some explanations
help getting around.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, zzag, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D23915
Summary:
Allows a compositor to set a proxy surface to handle drag and drop
operations place of the actual surface the drag originated from.
One proxy surface can handle multiple origin surfaces at the same time. These
need to get registered once. The active remote surface gets set when a pointer
button is pressed on the surface.
Test Plan: Manually with KWin's Xwayland DnD patches.
Reviewers: #kwin
Subscribers: davidedmundson, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D15421
Summary:
How drag'n'drop works on Wayland:
When a surface has a pointer grab and a button pressed on the surface
(implicit grab) the client can initiate a drag'n'drop operation on the
data device. For this the client needs to provide a data source
describing the data to be transmitted with the drag'n'drop operation.
When a drag'n'drop operation is active all pointer events are interpreted
as part of the drag'n'drop operation, the pointer device is grabbed.
Pointer events are no longer sent to the focused pointer but to the
focused data device. When the pointer moves to another surface an
enter event is sent to a data device for that surface and a leave
event is sent to the data device previously focused. An enter event
carries a data offer which is created from the data source for the
operation.
During pointer motion there is a feedback mechanism. The data offer
can signal to the data source that it can or cannot accept the data
at the current pointer position. This can be used by the client being
dragged from to update the cursor.
The drag'n'drop operation ends with the implicit grab being removed,
that is the pressed pointer button which triggered the operation gets
released. The server sends a drop event to the focused data device.
The data transfer can now be started. For that the receiving client
creates a pipe and passes the file descriptor through the data offer
to the sending data source. The sending client will write into the
file descriptor and close it to finish the transfer.
Drag'n'drop could also be initiated through a touch device grab, but
this is not yet implemented.
The implementation in this change focuses on the adjustments for pointer.
For the user of the library drag'n'drop is implemented in the
SeatInterface. Signals are emitted whenever drag is started or ended.
The interaction for pointer events hardly changes. Motion, button press
and button release can still be indicated in the same way. If a button
release removes the implicit grab the drop is automatically performed,
without the user of the library having to do anything.
The only change during drag and drop for the library user is that
setFocusedPointerSurface is blocked. To update the current drag target
the library user should use setDragTarget. Sending the enter/leave to the
data device gets performed automatically.
The data device which triggered the drag and drop operation is exposed
in the SeatInterface. The user of the library should make sure to render
the additional drag icon provided on the data device. At least QtWayland
based applications will freeze during drag and drop if the icon doesn't
get rendered.
The implementation is currently still lacking the client side and due to
that also auto test. It's currently only tested with QtWayland clients.
Reviewers: #plasma, sebas
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1046
The selection is supposed to be sent to the DataDeviceInterface just
before getting keyboard focus. In order to do that the SeatInterface
keeps track of the DataDeviceInterface which is the current selection
and the DataDeviceInterface of the focused keyboard client.
SeatInterface friends DataDeviceManagerInterface so that the latter
can register each created DataDevice for the SeatInterface.
The Resource base class is supposed to be used by all interface
classes which get created for a wl_resource.
Most interface classes are adjusted, but there are some exceptions:
* BufferInterface: is different as the wl_resource is already created
* PointerInterface and KeyboardInterface: those two need changes, the
implementation differs from all other interface implementations.
Only selection part is implemented, drag'n'drop still needs to be
implemented.
Unit test is not properly testing whether the data can be transferred.
This needs some better architecture to have multiple processes which
perform the source and target part.
