[kwayland] Clipboard Manager protocol
Open, Needs TriagePublic

Description

A dedicated protocol is required to forward all clipboard changes to Klipper and allow Klipper to always update the clipboard content.

WIP branches exist, currently at unit test phase

sitter added a subscriber: sitter.
sitter assigned this task to graesslin.Nov 7 2016, 2:51 PM

We should talk to GNOME and wlroots about a common protocol for this functionality.

Is this task currently still actively being worked on? Otherwise I put it back in the Backlog for now.

apol added a subscriber: apol.Feb 19 2019, 1:35 PM

KDE Connect needs something like that for the clipboard plugin too.

This is wanted for KDE Connect too

romangg added a comment.EditedJul 20 2019, 2:47 PM

Problem description

On Wayland data offers are sent directly from a client as data source to another client's data device. In particular:

  1. For security reasons it is not per se possible for clients to read or write on arbitrary data offers. KWin for example only allows the currently active client to do that.
  2. Data offers get lost when the data source client closes the Wayland connection.

(1) is desired behavior but we want out clipboard manager Klipper to be an exception. (2) is unwanted in general for small data offers.

Goals

  • Allow Klipper and only Klipper to eavesdrop on selections.
  • Give selection source to Klipper when no other client provides it. Allows to provide data after other client goes down with the data source.

Constraints

  1. Passwords must not be copied to Klipper history. Possible when data source provides x-kde-passwordManagerHint mimetype. KeepassXC does this since version 2.4.0.
  2. Clients killing off their data source after data was sent once. This is probably not possible to handle in all cases since we need to at least transfer once to Klipper besides sending to the other client and we might abort sending to Klipper if the data is too large.
  3. We need to buffer content directly in case the client connection dies down later on. We don't want to do this in KWin, so always directly transfer to Klipper.

Possible solutions

wlroots has the wlr-data-control-unstable-v1 protocol for clipboard managers. It's on the one hand a bit clunky because it's just a copy of the respective core Wayland interfaces, on the other side this solution is genius because there is no need for another specialized interface. The question is if this integrates nicely with our KWayland code which is complicated in regards to data sharing.

An alternative would be to implement a simple protocol that just activates a client as clipboard manager and then for every data source a data offer will first get routed to the clipboard manager before being sent to currently focused one. This could be part of plasma-window-management protocol. Such a clipboard manager could maybe not use the Wayland core data protocol for normal data transfers anymore in a sensible way.

Another question is if we should just directly replace any client's data source with the clipboard manager ones in case the clipboard manager buffers the data offer. In this case we would need an additional request for the clipboard manager in comparision to wlroot's protocol.

davidedmundson claimed this task.
davidedmundson added a subscriber: graesslin.
evpokp added a subscriber: evpokp.Oct 6 2019, 7:59 AM
mzramli added a subscriber: mzramli.Dec 6 2019, 1:36 PM
ktonga added a subscriber: ktonga.Sun, Jan 19, 8:19 AM