We use gtk_clipboard_set_with_owner() to set clipboard targets, not full data. Data is stored in a remote server. Later, when really the user wants the data on his desktop, he does a paste operation and the real transfer begins.
Now, mutter clipboard manager seems to break this: every time we set clipboard targets with gtk_clipboard_set_with_owner(), mutter clipboard manager immediately requests all the data from our application, triggering an “expensive” data transfer from remote server. Then it will do some conversions and store it locally. Sometimes it decides to not convert, so a subsequent paste action, will trigger a second expensive data transfer.
This conversion is a problem too: it does some assumptions which can be poison for applications, see for example the bad effects of one of these wrong assumptions here https://gitlab.gnome.org/GNOME/mutter/commit/0e0dae2774512ae0b0827a54df37dd0dd349eda5 and here https://gitlab.com/Remmina/Remmina/issues/2062
The advantage of having making gtk_clipboard_set_with_owner() (or XSetSelectionOwner) to require data only at the “paste” time, seem to be completely disappeared under mutter (tested on Ubuntu 19.10).
Should we abandon gtk_clipboard_set_with_owner() and forget to optimize clipboard transfers? Or am I missing something?