On Fri Feb 7 09:42:37 2025 +0000, Alexandros Frantzis wrote:
Some more thoughts... This MR is based on the standard `wl_data_device`, which comes with all the constraints and complications discussed in the description (needs app focus etc). There are some other approaches which I would like to present for consideration:
- (Current MR) Use wl_data_device trying to fit into current infrastructure.
- + Standard clipboard protocol, universal
- - Complexity due to interactions between clipboard manager window
and foreground window
- - Doesn't work with multiple desktops (see @littlewu2508 comment above)
- Use wlr-data-control (and its recent successor [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/33...)):
- + Unconstrained clipboard access, reduces winewayland
implementation complexity
- - Although it's widely supported
(https://wayland.app/protocols/wlr-data-control-unstable-v1#compositor-suppor...) it's not universally supported. Notably mutter is not expected to support it any time soon.
- - It's considered "privileged", uncertain whether compositors may
try to limit which applications can access it (unlikely though) 3. Use wl_data_device with temporary "invisible" windows to get the focus
- - Seems fragile and requires some method (compositor specific
protocols) to ensure we get the focus
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.