When a Gtk application on Wayland, having claimed the clipboard, receives a request for clipboard data, the string that identifies the type of data being requested is processed by gdk_intern_mime_type. This leads to any requests for data of a type that does not contain the character “/” being essentially rejected, by closing the file descriptor for the transfer without having attempted to write any data to it. However, it is possible to construct a GdkContentProvider containing one or more invalid types, that is, types a Gtk application will not send over the clipboard, and to claim the clipboard with it, making an offer of all the types it can (and cannot) provide in the process.
Why is this? Why is it so important for type strings on the clipboard to have the structure of MIME types, that nothing lacking that structure is provided? I’ve seen it said that using real MIME types is good for interoperability, since a standardized lingua franca of type names is more likely to be recognized by unknown programs foreign to Gtk and the GNOME ecosystem, and this does make sense. But surely a concern for interoperability would also say that if a foreign program is interested in pasting data with a type identified by a string of arbitrary bytes (none of which is a “/”), and the author of a Gtk application wants to make data with that type available, it should work.
Or, perhaps more realistically, if a clipboard manager for an environment that is decidedly not GNOME has implemented a hacky, in-band way of detecting sensitive data that it shouldn’t copy and keep in its history, by looking for the magic string “secret” provided as the “type” x-kde-passwordManagerHint alongside real data of real types, shouldn’t a Gtk-based password manager be able to interact with that? It would be hard to say a hint like this is really media of its own type; it’s more properly thought of as metadata about the clipboard data offer that includes it, and it ought to be tightly associated with the particular data offer it applies to lest time-of-check vs. time-of-use issues be introduced, but the current Wayland protocols for clipboard data don’t really provide a dedicated side channel for this sort of metadata about data offers. And perish the thought of defining a new Wayland clipboard protocol just for this feature! There’s plenty of wiggle room in the current protocols anyway, that’s why this works for KDE at all.
To me, it seems that it ought to be at least possible for Gtk applications to provide clipboard data under type strings that are as arbitrary as the underlying platform will let applications get away with, but perhaps I’m missing something about the bigger picture. If I am, please enlighten me, because I wouldn’t want to start proposing particular changes to Gtk (or even chime in on an issue that’s been open for nearly five years) if I’m not sure I understand why things are as they are. And neither am I about to go to KDE and insist, without a solid justification, that their clipboard manager must look for a new, redundant, more MIME-type-shaped alias of x-kde-passwordManagerHint for Gtk apps to be able to use, when existing non-Gtk apps like wl-copy and KeepassXC are already using it as it is with no trouble.
I began my descent of this rabbit hole because I use KeepassXC on KDE Plasma, and I would like to be able to replace KeepassXC with GNOME Secrets, but I’m quite fond of KeepassXC’s ability to prevent copied passwords from showing up in my clipboard history, and GNOME Secrets can’t add this feature at time of writing because it’s a Gtk app.
P.S: I began drafting this post a week ago, and I suppose it’s just my luck (whether it’s good or bad luck, I can’t say) to find my misery already has some company.