Add Clipboard support for RemoteDesktop via org.freedesktop.portal.Clipboard

[maxhbooth]

This PR is to add clipboard controls for RemoteDesktop as described in #843.

xdg-desktop-portal-gnome

Fix #843

[gasinvein]

It it possible to use this without RemoteDesktop? I believe a Clipboard portal would be useful on its own, as a more convenient way to interact with the clipboard on Wayland.

[jadahl]

It it possible to use this without RemoteDesktop? I believe a Clipboard portal would be useful on its own, as a more convenient way to interact with the clipboard on Wayland.

Why would you want that? Clipboard in the form that remote desktop applications need should not be exposed to applications for convenience, since it avoids limiting clipboard content to the focused application and user interaction on that application. Doing that has very large privacy implications.

[gasinvein]

It it possible to use this without RemoteDesktop? I believe a Clipboard portal would be useful on its own, as a more convenient way to interact with the clipboard on Wayland.

Why would you want that?

One example I have in mind is a translation app that has a feature to translate selected text and put translation back to clipboard; this can be triggered without interacting with the app main window, via hotkey or tray icon menu.

Clipboard in the form that remote desktop applications need should not be exposed to applications for convenience, since it avoids limiting clipboard content to the focused application and user interaction on that application. Doing that has very large privacy implications.

I suppose user has to grant the app permission to interact with clipboard first?

[maxhbooth]

I suppose user has to grant the app permission to interact with clipboard first?

Yes. We certainly don't want applications to control a user's clipboard without their consent.

One example I have in mind is a translation app that has a feature to translate selected text

In #843 it was mentioned that this interface could be useful for the InputCapture portal in the future, which might solve this use case?

[gasinvein]

One example I have in mind is a translation app that has a feature to translate selected text

In #843 it was mentioned that this interface could be useful for the InputCapture portal in the future, which might solve this use case?

Sorry, I don't know anything about the proposed InputCapture portal.

[maxhbooth]

@jadahl, there hasn't been any progress on this PR for awhile, is there anything I should do to get some feedback on it?

[jadahl]

@jadahl, there hasn't been any progress on this PR for awhile, is there anything I should do to get some feedback on it?

I'll try to do a round of review as soon as I can.

[jadahl]

Haven't looked close at the actual C code yet, as if we're dropping the Request method dance, it'll likely look different enough to invalidate any review I do today.

[maxhbooth]

@jadahl, thanks for your first review! I think I've addressed all your comments now, if you have time for another round 😄

[garnacho]

I've read through the changes and the proposed API makes sense to me. I feel there should be further documentation on the expected order of events after the SelectionTransfer signal, e.g. how to react to transfer requests of unrelated mime types or if no FD can be obtained.

In that regard, I mildly wonder if passing an FD should be implicitly considered success, writing on an end of a pipe accounts on the other side reading or the pipe will grow full and writes will stall, and having to wait to the end of the transfer for a SelectionWriteDone verifying the success means the other end needs to cache the full result before doing anything useful with it.

[pnowack]

Since the portal clipboard API here is based on the private clipboard API between mutter and g-r-d, there is something to note here:

There are thoughts about changing the SelectionWrite and SelectionWriteDone methods in a way by using lists of what they actually currently have for arguments.
The reason is to group calls to kill latency when handling multiple clipboard content requests.
Due to time constraints, this was so far not realized for mutter and g-r-d (other tasks got priority and I only was made aware of this PR today) and so these changes did not went in yet.

For the portal API we probably wanna change the handling in that direction, so that mutter would not have two paths for handling selection writes and their results.
For SelectionWriteDone this would mean, a list would be submitted, where each element contains the serial and its sucess value.
I don't remember my thoughts about SelectionWrite to what it should be changed to be able handle multiple requests at the same time, but using a list of elements of (serial, fd) might be sufficient for this.

[matthiasclasen]

Since this is only about remote desktop sessions, I don't think it should be called org.freedesktop.portal.Clipboard. That name is confusing and implies that this also covers local clipboards, which are handled via display server protocols already.

[jadahl]

Since this is only about remote desktop sessions, I don't think it should be called org.freedesktop.portal.Clipboard. That name is confusing and implies that this also covers local clipboards, which are handled via display server protocols already.

This is not a separate clipboard portal, but a way to hook up clipboard to the remote desktop portal. Since we might want clipboard to other portals (e.g. input capture), it makes sense to keep it separate, and not tied to remote desktop, otherwise we need to copy paste the whole API in every place its used, including follow up fixes / changes.

[maxhbooth]

Thanks @scmv! I've updated the serials in SelectionWrite to use au instead of a(u) now.

[maxhbooth]

@jadahl I added some tests and finished your last code review

[maxhbooth]

fyi I think this PR is just waiting for more maintainers to chime in with any thoughts

[jadahl]

This needs a rebase to drop the autotools parts.

[maxhbooth]

This needs a rebase to drop the autotools parts.

Done!

[jadahl]

I think this is more or less ready to land. I'd like to go back to a simpler previous version (see comment about SelectionWrite(Done) about what/why), but other than that it seems ready.

[maxhbooth]

@jadahl Done!

[jadahl]

Everything lgtm. Planning to land this within some days, e.g. monday next week, if no-one objects before that.