On Fri Feb 14 11:45:06 2025 +0000, Alexandros Frantzis wrote:
Here is the alternative proposal based on the data-control protocols: https://gitlab.winehq.org/wine/wine/-/merge_requests/7336
Can we back up to explain the specific problems of using wl_data_device, there might be some things we can do within the current constraints.
This MR tries to work within the current Wine clipboard Wine by forwarding relevant clipboard messages to the foreground window which is likely to have the keyboard focus and that can actually handle them
I don't fully understand this part. If you are notified on the data_device about a change, you can still forward this message to all Wine windows whether they have focus or not.
The part about retrieving
- It's considered "privileged", uncertain whether compositors may try to limit which applications can access it (unlikely though)
I can confirm that Kwin already does limit who can access the clipboard manager to any flatpak'd apps. It's not a direction we want applications to go.
That doesn't mean we won't bend over backwards to help with whatever, I would rather explore a design that allow us to set the clipboard even without focus with wl_data_device than to allow all wine apps to read the clipboard without focus via ext-data-control if that's what's needed to solve your problems.
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
The problem of having to shim an immutable existing API into a completely different awkward Wayland API is not a Wine specific problem. All the cross-platform toolkits have their own set of very similar challenges that we keep having issues with. There's more commonality here than you might think.