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.
When the user has some sort of hardening going on, we might not be able
to read the Wine process's memory. In that case this check would return
`false` even though the process is still running. To combat this, we
should explicitly check for `EINVAL` which is returned when the file
doesn't exist at all or when it's a broken 'symlink' (even though it
isn't really a symlink).
Robbert van der Helm