wlr-data-control makes offers to clients that sent them

[soreau]

When using wlr-data-control protocol and listening for offers, any offer sent is also broadcast back to the client that sent it. This means that when the client tries to receive the data, it read()s from a fd that the same client has to write(). Of course, this causes the client to block forever. It doesn't really make sense to send something back to the client that it just sent. This makes me think that the protocol should state that sent sources are not rebroadcast back to the same client as offers. Thoughts?

[soreau]

I wrote an example program to demonstrate the problem.

[bugaevc]

It doesn't really make sense to send something back to the client that it just sent. This makes me think that the protocol should state that sent sources are not rebroadcast back to the same client as offers. Thoughts?

Disagree. Just as with core Wayland wl_data_*, and other Wayland clipboard protocol extensions, clients always get sent the currently active/relevant offer, even if they created it themselves. What might make sense is adding additional data to offers (e.g. in a form of an event on offers), specifying where they come from, in particular it could somehow specify if it comes from the same client.

But note that "the same client" is somewhat loosely defined — several independent parts of a program could use the same Wayland connection (thus appearing as the same client to the compositor) without knowing much about each other; and one program can be broken up into multiple processes that use separate Wayland connections. So it's not as clear-cut.

[soreau]

I was thinking about implementing a simple clipboard manager, that runs as a daemon process and saves the current selection so that it can be pasted after the client is destroyed. However with the current design, if the clipboard manager makes an offer when it gets an offer, the selection is canceled in the client. So e.g. with gtk clients, this makes the selection immediately become unselected. The clipboard manager could save the selection when it gets an offer and then make its own offer when the client is destroyed, but there is no offer_destroyed event. Do you think it would make sense to add an offer_destroyed event that fires when a client with an outstanding offer is destroyed so that such a clipboard manager daemon could make an offer in this case? Currently if text is highlighted and copied in a client and then it is closed, both 'clipboards' are empty and trying to middle-click-paste or regular-paste results in nothing being pasted.

What might make sense is adding additional data to offers (e.g. in a form of an event on offers), specifying where they come from, in particular it could somehow specify if it comes from the same client.

This sounds like a good idea.

But note that "the same client" is somewhat loosely defined — several independent parts of a program could use the same Wayland connection (thus appearing as the same client to the compositor) without knowing much about each other; and one program can be broken up into multiple processes that use separate Wayland connections. So it's not as clear-cut.

If there are such clients, I expect that they handle the messages given and dispatch them accordingly to other parts of itself.

[bugaevc]

The clipboard manager could save the selection when it gets an offer and then make its own offer when the client is destroyed, but there is no offer_destroyed event. Do you think it would make sense to add an offer_destroyed event that fires when a client with an outstanding offer is destroyed so that such a clipboard manager daemon could make an offer in this case?

There's no offer_destroyed event, but you get selection(nil) whenever the active offer is destroyed/invalidated, so you could use that. And there are clipboard managers (e.g. clipman) that do that.

However, I've long believed that selection(nil) events are not enough for proper clipboard persistence implementation. I've most recently summarized my thoughts on the matter here, so please read that.

[emersion]

when the client tries to receive the data, it read()s from a fd that the same client has to write(). Of course, this causes the client to block forever

Even if the offer comes from another client, said other client may block for a long time. Your client should perform non-blocking reads and writes instead.