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`.
This should in theory prevent Nimble Kick from triggering a stack
overflow when the event loop timer procs before `IPlugView::attached()`
gets called and the plugin hasn't been registered yet. I haven't seen
any other VST3 plugins trigger a race condition here.
In some cases we would treat dead processes as not running (we could
also get EAVAIL instead of EINVAL, so it's better to just check the one
thing we should treat as a success instead).
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.
We should of course not expect all global memory to be a HDROP, oops.
Apparently REAKTOR sometimes uses the drag-and-drop system for its own
internal data.
Specially for @AVLinux. We currently don't build a 32-bit version of
yabridgectl though, so you'd still need that if you want to use yabridge
on an _actual_ 32-bit system.