We should only enforce the check whether a data source has set the
actions for drag on drop on a selection if it's at least version 3. For
backward compatibility we used to set a default action which would
ensure that a version <3 and >3 client can interact with each other. But
due to that the action was set to a default value which breaks any
selection. Sorry about that.
This change ensures the backward compatibility behavior does not break
selection.
As the regression causes all clients to quit it is a severe regression
which requires fast action. Due to that I'm doing a maintainer push
without review. I encourage everyone to do a post commit review.
Sorry for not noticing the regression before. The backward compatibility
was the last thing I added in that patch set and apparently I did not
run all tests again.
Summary:
The main difference compared to version 2 is additional drag and drop
actions. The source and destination can negotiate whether the data
should be copied or moved or the user should be asked for either or.
This seems to be important for GTK, but is not yet implemented in Qt.
The main motivation for adding support is that it is required by SDL to
launch on Wayland.
BUG: 386993
Test Plan: Extended test case, sdl apps now start
Reviewers: #frameworks, #plasma, #kwin
Subscribers: plasma-devel
Tags: #plasma_on_wayland, #frameworks
Differential Revision: https://phabricator.kde.org/D9136
Summary:
According to the Wayland documentation a data source needs to be
cancelled whenever it is no longer valid. A reason for no longer being
valid is that the data source has been replaced by another data source.
So far KWayland did not implement this aspect which resulted in clipboard
breaking in QtWayland applications. As soon as one copied once from an
application it was no longer possible to paste to it from another
application.
With this change the data source gets properly cancelled and also
ensured that the server code doesn't run into a possible crash condition
when trying to cancel an already unbound data source.
BUG: 368391
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D2743
Summary:
This change standardizes the behavior regarding the destructor request.
The destructor should destroy the resource and nothing else. The
Wayland library invokes the static unbind method once the resource is
destroyed. The implementation provided by Resource::Private::unbind
triggers a delete later on the Resource. So there is no need to trigger
a deleteLater from the destructor request callback.
This change adds a generic implementation to Resource::Private which is
now used by all inheriting classes replacing the custom implementations.
Test Plan:
For a few Resources the test is extended to ensure that the Resource
gets deleted on server side.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1679
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
Required information is passed through the ctor of Private.
::create is still virtual as ShellSurfaceInterface is retrieving
client information. This can be fixed once we have a better wl_client
encapsulation class.
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.
