wayland: add wlr-data-control protocol #1151
Conversation
kchibisov
force-pushed
the
smithay-wlr-data-control
branch
5 times, most recently
from
72cbfb6 to
f8cd94d
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #1151 +/- ##
=======================================
Coverage 22.57% 22.58%
=======================================
Files 146 152 +6
Lines 23526 23614 +88
=======================================
+ Hits 5312 5334 +22
- Misses 18214 18280 +66
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
While I really like the simplicity of the data_control implementation, there is no way to filter what wlr_data_device-clients see, right?
Would it maybe make sense to add a method to the DataControlHandler to make it possible for downstream to filter selections send? (Default implementation could be "allow all" and it seems like send_selection would be an easy point to hook into.)
I don't have any particular use-cases in mind for this, but the current implementation feels like all or nothing. Either I want the protocol with all of the security problems it brings, or I don't advertise it at all.
Overall though, this is a great PR with so many good improvements. Thanks a bunch!
wlr_data_control is a protocol used to implement clipboard managers or access clipboard without creating a window. The implementation of it ties to regular selections, thus the selection handling was unified to reduce the maintainance burden. The present selection modules, like `walyand/primary_selection` and `wayland/data_device` moved into the new `wayland/selection` module. Keeping their original implementation, where it was possible. The new selection module uses the common structure of `seat_data`, `device`, `source`, and `mod.rs` used in the said above modules, however it uses the hand-rolled dynamic dispatch with the `selection_dispatch!` macro. The offers and selection replies are all handled together, so the code is unique in the most cases. As a side effect of the selection update and merging the handling of the primary and clipboard selection into the single `SelectionHandler` trait (users could still just use one of them, it's not a must to have both), the xwayland was changed to use some types from the `wayland/selection` module.
kchibisov
force-pushed
the
smithay-wlr-data-control
branch
from
f8cd94d to
8e779d0
Compare
wlr_data_control is a protocol used to implement clipboard managers or
access clipboard without creating a window. The implementation of it
ties to regular selections, thus the selection handling was unified
to reduce the maintainance burden.
The present selection modules, like
walyand/primary_selectionandwayland/data_devicemoved into the newwayland/selectionmodule.Keeping their original implementation, where it was possible.
The new selection module uses the common structure of
seat_data,device,source, andmod.rsused in the said above modules, howeverit uses the hand-rolled dynamic dispatch with the
selection_dispatch!macro. The offers and selection replies are all handled together,
so the code is unique in the most cases.
As a side effect of the selection update and merging the handling of
the primary and clipboard selection into the single
SelectionHandlertrait (users could still just use one of them, it's not a must to have
both), the xwayland was changed to use some types from the
wayland/selectionmodule.--
I haven't tested XWayland, but the protocol is implemented in anvil, and it should be dead simple to add into any compositor.
The implementation was tested with
wl-clipboardand YaLTeR/niri#27