Clipboard manager use case

[Albert Vaca]

Hi there!

I would like to start a discussion about the need of a protocol for
clipboard management in Wayland. As far as I know, the current approach for
clipboard managers and similar apps requires them to be implemented as part
of the compositor. This is of course a limitation for third party clipboard
managers and apps like KDE Connect, which I maintain.

For some context, KDE Connect is a service that bridges your smartphone and
your computers together, with features like wireless file transfers, shared
notifications, or a shared clipboard across devices (on X11).

For the clipboard synchronization in KDE Connect to work on Wayland, we
need a way to:
- Change the contents of the clipboard.
- Get notified about the contents of the clipboard when it changes.

I think our needs are very similar to those of clipboard managers, so
probably one single protocol could address both necessities.

What do you think? Should I make a protocol proposal for this use case? Is
there any similar use case that I'm overlooking?

Albert

[Simon Ser]

Hi,

I would like to start a discussion about the need of a protocol for clipboard
management in Wayland. As far as I know, the current approach for clipboard
managers and similar apps requires them to be implemented as part of the
compositor. This is of course a limitation for third party clipboard managers
and apps like KDE Connect, which I maintain.
For some context, KDE Connect is a service that bridges your smartphone and
your computers together, with features like wireless file transfers, shared
notifications, or a shared clipboard across devices (on X11).
For the clipboard synchronization in KDE Connect to work on Wayland, we need
- Change the contents of the clipboard.
- Get notified about the contents of the clipboard when it changes.
I think our needs are very similar to those of clipboard managers, so
probably one single protocol could address both necessities.
What do you think? Should I make a protocol proposal for this use case? Is
there any similar use case that I'm overlooking?

This is something wlroots would also be interested in. This could be useful for
xclip-like clients and "real" clipboard managers (which let you e.g. navigate in
the clipboard history).

I've already started to work on a protocol [1]. It would be nice if we could
share it. Questions and comments welcome!

Note that there are security considerations that need to be taken into account.

Thanks,

[1]: https://github.com/swaywm/wlr-protocols/pull/25

---
Simon Ser
https://emersion.fr

[Albert Vaca]

Post by Albert Vaca
Hi,

Post by Albert Vaca
I would like to start a discussion about the need of a protocol for

clipboard

Post by Albert Vaca
management in Wayland. As far as I know, the current approach for

clipboard

Post by Albert Vaca
managers and similar apps requires them to be implemented as part of the
compositor. This is of course a limitation for third party clipboard

managers

Post by Albert Vaca
and apps like KDE Connect, which I maintain.
For some context, KDE Connect is a service that bridges your smartphone

and

Post by Albert Vaca
your computers together, with features like wireless file transfers,

shared

Post by Albert Vaca
notifications, or a shared clipboard across devices (on X11).
For the clipboard synchronization in KDE Connect to work on Wayland, we

need

Post by Albert Vaca
- Change the contents of the clipboard.
- Get notified about the contents of the clipboard when it changes.
I think our needs are very similar to those of clipboard managers, so
probably one single protocol could address both necessities.
What do you think? Should I make a protocol proposal for this use case?

Is

Post by Albert Vaca
there any similar use case that I'm overlooking?

This is something wlroots would also be interested in. This could be useful for
xclip-like clients and "real" clipboard managers (which let you e.g. navigate in
the clipboard history).
I've already started to work on a protocol [1]. It would be nice if we could
share it. Questions and comments welcome!
Note that there are security considerations that need to be taken into account.
Thanks,
[1]: https://github.com/swaywm/wlr-protocols/pull/25
---
Simon Ser
https://emersion.fr

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.

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.

[1] https://developer.android.com/reference/android/content/ClipboardManager

Would something on those lines cover your needs, or would you miss
something?

Albert

[Simon Ser]

Post by Albert Vaca
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

Post by Albert Vaca
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]: https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-data-sharing

[Albert Vaca]

Post by Simon Ser

Post by Albert Vaca
Hi Simon,
I've given your proposal a read, and found it quite complicated. There

are

Post by Albert Vaca
concepts like "data device" or "data source" that seem too abstract from

my

Post by Albert Vaca
point of view. I guess your idea is that the clipboard is just one of

many

Post by Albert Vaca
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.
* 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

Post by Albert Vaca
In my opinion, I would prefer a protocol that just talks about the

clipboard and

Post by Albert Vaca
its contents. Something similar to the Android Clipboard Manager API

[1], on

Post by Albert Vaca
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.
https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-data-sharing

Simon,

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.

Albert

[Simon Ser]

Post by Albert Vaca
Simon,
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.

Yeah, that's the motivation behind the protocol: consistency.

I was also confused when I first read the core Wayland protocol, it takes time
to understand why it's built like this, but it does make sense in the end. ;)

Post by Albert Vaca
That said, you have my +1 on your proposal.

Sweet

Post by Albert Vaca
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.

I'd really love to have some KWin guys have a look at it. If that can't happen,
I'll bump it and it'll go through the normal wlr-protocols review process.

Do you know if there is anyone from the KDE side interested in reviewing this?

Thanks,

Simon

[Roman Gilg]

Post by Simon Ser

Post by Albert Vaca
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.

I'd really love to have some KWin guys have a look at it. If that can't happen,
I'll bump it and it'll go through the normal wlr-protocols review process.
Do you know if there is anyone from the KDE side interested in reviewing this?

I already looked through the protocol a bit. But for a more thorough
review I would first need to find some time for it. But maybe a better
approach would be directly trying to implement the protocol in KWin
and make use of it in KDE Connect. After all besides the data
device/source/offer heavy protocol language it doesn't look too
complicated. This way we can maybe spot issues we otherwise would
overlook.