On Fri Feb 7 09:44:18 2025 +0000, Rémi Bernon wrote:
Thanks for clarifying the options. I don't think 3) is right so let's only consider 1) or 2). To me, it looks like the purpose of protocol 1) is to prevent background windows/processes from accessing the clipboard. In Windows IIUC every process can. Both seem to be in contradiction, and I feel that implementing the protocol in a way where we would allow every Wine process to access the clipboard through the foreground window violates the spirit of the protocol. Not that I mind too much, but if there's an alternative that's explicitly meant to allow privileged access to the clipboard, and if that's what Windows does, then it looks to be a better match. And if it's easier to implement, then even better. Still, if we think that having a wider support is better, we could still decide to implement 1) but I'm not sure we should work around its limitation, and we should also only allow the foreground window to access the clipboard in the way it's integrated with the Windows side. In a general sense IMO at some point compositors will have to adjust their design to their users, and decide to implement things that are required to support some applications. There's only so much we can do on our side and although we're happy to add Wayland support, its limitations make it difficult to have good integration with Wine. I was even thinking that, instead of implementing protocols that are inherently incompatible with Win32, the best way forward would be to design and expose our own set of protocols that would fit exactly the Win32 model, and let compositors decide if they want to support Wine or not.
Thanks @rbernon. The more I consider `{wlr,ext}-data-control` the more enticing it looks for our use case. So an implementation based primarily on it, plus a *simple* fallback to `wl_data_device` seems like a good way forward.