Clipboard manager use case
albertvaka at gmail.com
Fri Nov 9 14:01:30 UTC 2018
On Fri, Nov 9, 2018 at 12:16 PM Simon Ser <contact at emersion.fr> wrote:
> On Thursday, November 8, 2018 3:40 PM, Albert Vaca <albertvaka at gmail.com>
> > Hi Simon,
> > I've given your proposal a read, and found it quite complicated. There
> > concepts like "data device" or "data source" that seem too abstract from
> > point of view. I guess your idea is that the clipboard is just one of
> > possible "data devices", but I find this unnecessarily generic.
> No, this is not it. There is only one global "clipboard". The protocol
> aim to be generic, it just uses different names. As said in the pull
> this protocol is just a copy of the "clipboard" interfaces in the core
> protocol. I suggest you read  which gives an overview of how this works.
> * 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
> , on
> > Wayland.
> Unfortunately you won't be able to create a Wayland protocol from a Java
> Wayland is not an RPC protocol, it's an asynchronous protocol.
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...
More information about the wayland-devel