The goal is to have the window be at (0, 0), while Wine's X11 event
layer thinks it is at the actual screen coordinates. This is needed to
prevent drawing issues with buggy plugins that rely on absolute screen
coordinates to draw their GUI.
Instead of ignoring all `NonlinearVirtual` events. This lets us release
focus when instantly moving the mouse from a plugin GUI to something
else. This generates `NonlinearVirtual` event, and previously we ignored
those because that also happens when opening a dropdown menu in a TDR
plugin (which uses popup windows instead of actual dropdowns).
We'll need this for the `LeaveNotify` because `GetCursorPos()` updates
only once every 100 ms, which means that it would still point to the old
window we're actually leaving.
This will let us detect other, non-wrapper windows to the right and to
the bottom of a plugin GUI. Useful for drag-and-drop so we don't end up
overriding Wine's internal drag-and-drop mechanism.
This is needed for Tracktion Waveform because they shift our wrapper
window a bit downwards. Otherwise opening the window while your mouse
cursor is already inside of it would trip up Wine's coordinates.
We moved this from `parent_window` to `wine_window` in
974951e966 to account for Waveform adding
an offset in their windows, so now that we have `wrapper_window` we
should be translating from there instead.
Wine is weird. The whole reason why we're doing these weird things is
because Wine somehow tries to delete the window twice. If we don't call
`xcb_query_tree()` here (and get an error back), then we're back at the
error we tried to solve. Apparently this works, and given that noone
dares touching Wine's X11drv code I won't ask any further questions.
This reverts commit d3d21c65f4.
On second thought, Wine actually handles things better this way. We want
to avoid both hangs and the Wine window becoming visible, and this
achieves both of those things. We should just silence the warning.
We still need to make sure this window resizes properly, but this should
prevent the host from interacting with the full screen `ConfigureNotify`
events we keep sending to `wine_window`.
I've seen this happen once or twice. Earlier on (in #40) we could get
away with just reparenting the window another time. But here both
reparents succeed, and the issue still happens. But a reparent notify
for `parent_window` did appear on system affected by this issue, which
is very odd. Hopefully this will help.
This is the same way (minus the mapping check part) that `xprop` and
`xwininfo` filter windows when clicking on them. REAPER's toplevel
window apparently doesn't process any keyboard input when the mouse
cursor is located outside of that window.
REAPER initializes the plugin's editor first before reparenting the
parent window to the FX window, so our `topmost_window` didn't actually
refer to the FX window.
Robbert van der Helm