On Sat Dec 7 21:14:33 2024 +0000, Robbert van der Helm wrote:
Embedding the entire virtual desktop window will sadly not work for this use case. The context here is that professional audio production software usually lets users use third party synthesizers and effects through various plugin systems. Those plugins are native shared libraries that implement one of the various standardized plugin ABIs. Most of these plugins are only available for Windows and macOS, which means they can't be loaded on Linux. Yabridge makes it possible to use these plugins on Linux by acting as both a plugin and a plugin host, and then passing through any and all function calls made by either the native host or the Windows plugin so it appears that they're talking to a regular old native plugin or host. The thing is that users usually need to interact with those plugins through a custom GUI provided by the plugin. In all of the common plugin standards the host provides a native window handle that the plugin then embeds itself into (reparent on X11, child window on Windows, etc.). So to make this work, yabridge creates a Win32 window, asks the plugin to embed itself into that window, and then reparents the X11 window (i.e. `GetProp(hwnd, "__wine_x11_whole_window")`) into the X11 window provided by the host. This approach works surprisingly well, except for the aforementioned mouse coordinate offset thing. In the past yabridge was able to fix this by directly sending `ConfigureNotify` events to Wine without actually moving the window so Wine knows where the window is actually located on screen, but that no longer works with the stricter implementation from this PR. So my question is more or less: can we make this behavior work with the updated winex11 implementation, or would it be feasible to make Wine aware of this behavior so it would just work without having to inform Wine where on screen an embedded window is?
I don't know for sure but there are probably some ways to make it work. It works already more or less well with embedded systray windows, so maybe doing something similar could be enough.
Alternatively mouse input is mapped in `map_event_coords` and we preferred event root/x_root/y_root values when available because it avoided some inconsistencies when moving windows, but window positioning has been refactored lately, and maybe this isn't necessary anymore.
Using window-relative mouse input could solve your case too (or we could also perhaps consider a winecfg option to prefer it over absolute positions).