Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.

[Robbert van der Helm (＠robbert-vdh)]

On Mon Dec  2 22:41:17 2024 +0000, Rémi Bernon wrote:
> There has been various changes in the way we handle window positioning,
> and it's now probably more flexible to arbitrary X11 parent windows, but
> in any case we still always consider the X root window coordinates as
> the origin for the Win32 desktop.
> If you want to embed all Wine windows into another window and use its
> position as the Win32 desktop origin, it's basically what the "virtual
> desktop" mode is doing already. It's an option in winecfg, where we
> create a dedicated window for the Win32 desktop and every Wine window
> will be a child of it. You could probably then reparent the desktop
> window to the window you want?

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?