We accidentally reverted a little bit too much code in
762e622416. This didn't appear any sooner
because plugins are supposed to call `IPlugFrame::resizeView()` during
`IPlugView::attached()`, so this only affects plugins that don't confirm
to the spec.
This reverts commit ff76e482f2.
This was a workaround for a race condition in Nimble Kick when opening
the editor while the plugin has not yet been authorized (a Win32 timer
proc between `IEditController::createView()` and `IPlugView::attached()`
would cause a stack overflow because the plugin doesn't check if the
things it wants to use have actually been initialized yet).
But as it turns out, Bitwig Studio now calls
`IEditController::createView()` unconditionally when loading a VST3
plugin, regardless of whether the user wants to open the editor or not.
So this workaround would cause the message loop to be stalled
indefinitely until you open the editor. Since this would also cause
Nimble Kick to break in the Windows version of Bitwig, we'll simply
revert this workaround. If you need to activate the plugin on Linux, you
can load it in the Windows version of REAPER running under Wine instead.
After that the plugin will work just fine under yabridge.
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).
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.
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.
JUCE incorrectly calls `IComponentHandler::performEdit()` from the audio
thread instead of using the output parameter changes queue, so this
would also cause GUI resizes to be handled from the audio thread if they
come in at the same time as such a parameter change.
Robbert van der Helm