Clipboard manager use case

Albert Vaca albertvaka at
Fri Nov 9 14:01:30 UTC 2018

On Fri, Nov 9, 2018 at 12:16 PM Simon Ser <contact at> wrote:

> On Thursday, November 8, 2018 3:40 PM, Albert Vaca <albertvaka at>
> wrote:
> > Hi Simon,
> >
> > I've given your proposal a read, and found it quite complicated. There
> are
> > concepts like "data device" or "data source" that seem too abstract from
> my
> > point of view. I guess your idea is that the clipboard is just one of
> many
> > possible "data devices", but I find this unnecessarily generic.
> No, this is not it. There is only one global "clipboard". The protocol
> doesn't
> aim to be generic, it just uses different names. As said in the pull
> request,
> this protocol is just a copy of the "clipboard" interfaces in the core
> Wayland
> protocol. I suggest you read [1] which gives an overview of how this works.
> Basically:
> * There is one data device per seat
> * You can set the selection by creating a data source
> * You get get the current selection by using a data offer
> > In my opinion, I would prefer a protocol that just talks about the
> clipboard and
> > its contents. Something similar to the Android Clipboard Manager API
> [1], on
> > Wayland.
> Unfortunately you won't be able to create a Wayland protocol from a Java
> API.
> Wayland is not an RPC protocol, it's an asynchronous protocol.
> [1]:

Thanks for the clarification. I found the wording a bit confusing, but if
that's the wording already in use then I agree we should stick with it.

That said, you have my +1 on your proposal.

What do we need to do in order to move this forward? I see the proposal has
been up for some months but didn't get much attention.

If it is approved, I can probably make it happen on the KDE side, but it
would be nice have input from other compositors.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the wayland-devel mailing list