Adds timer_proc lambda for VST3 to check for size mismatches and trigger
a new resize to correct it through eventual consistency.
This is done to workaround an X11 sync issue where the plugin view would
end up smaller or larger than its wrapper window. In Ardour this could
result in the plugin becoming uninteractable.
For VST2 in Ardour, it seems Ardour is doing its own WM/wrapper window
thing too. In this case, the plugin gets absolute ConfigureNotify events
that are already in the root coordinate space, so just use those
coordinates and ignore the host window.
Also fix the dimensions, which should always be those of the parent
window, not the host window. If the parent is the host window, still
track its geometry separately, and just don't add in the host window
dimensions in this case either.
Ardour brings up the plugin UI before the host window is visible, and it
is missing some properties. Using WM_WINDOW_ROLE instead of WM_STATE
makes it work.
For reference, these are the properties that are set on the window at
the time of plugin GUI instantiation:
_NET_WM_ICON(CARDINAL) = Icon (16 x 16):
WM_WINDOW_ROLE(STRING) = "plugin_ui"
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 6294918
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_UTILITY
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x600d85
WM_CLIENT_LEADER(WINDOW): window id # 0x600001
_NET_WM_PID(CARDINAL) = 1604801
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "homura"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified size: 521 by 46
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "ardour-8.12.0", "Ardour-8.12.0"
WM_ICON_NAME(STRING) = "Audio 1: Melodyne (by Celemony) [VST3]"
_NET_WM_ICON_NAME(UTF8_STRING) = "Audio 1: Melodyne (by Celemony) [VST3]"
WM_NAME(STRING) = "Audio 1: Melodyne (by Celemony) [VST3]"
_NET_WM_NAME(UTF8_STRING) = "Audio 1: Melodyne (by Celemony) [VST3]"
We just need this constant, so there's no real need to add the
additional dependency. There's also no real harm in adding it, but it
would result in additional work for every packager.
This will cause the function to only be called on a `ConfigureNotify`
after all mouse buttons have been released. This prevents flickering
when dragging windows around.
This fixes Waves V13 VST3 plugins crashing when opening the editor. They
will likely still crash later on anyways because they're kinda broken.
Amazing.
I'm not a fan of Hungarian notation, but C++ kind of needs it with its
implicit `this`. And of all the common options for this, I find
suffixing members with an underscore the least offensive one.
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.
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.
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.
We cannot integrate this into our event loop like we planned, because
Wine a) grabs the mouse pointer so we cannot do that, and b) blocks the
GUI thread. So instead we will spawn our own thread and do polling based
XDND. When Wine's tracker window gets destroyed, we know that the left
mouse button has been released.
Juuso Kaitila