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.
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).
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.
This should fix#118 without breaking our _other_ workaround from
yabridge 3.4.0 to fix the issue where a plugin would freeze if it would
try to resize itself while at the same time it sent parameter changes
from the audio thread. (and both of these issues of course are caused by
the same JUCE bug)
This is super difficult to trigger on purpose, but I did run into it at
least once just now so it seems like a good idea to at least make sure
that this doesn't happen.
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.
This was left over from the original implementation, before we had this
smart pointer-singleton hybrid thing. There's already a handle stored
inside of `Editor`.
This should have been fixed as of yabridge 3.2.0 by adding doing a
reparent with a last second flush. Or at least, I haven't heard any
reports about this still being an issue.
Instead of while the tracker window is alive. Technically the plugin may
clean up their files after the tracker window is gone, but in practice I
haven't seen it happen.
The whole dropping code was nested in the wrong loop (oops), and we also
forgot to send any last spooled messages. We now also use a pair of
booleans instead of an optional boolean here because it makes the
conditionals a bit more readable.
Robbert van der Helm