e95f381fa0
Remove unnecessary unreparent check
...
Or at least, hopefully this is not needed.
2021-07-21 17:01:02 +02:00
e28bc63f8d
Also resize the wrapper window for VST3 plugins
2021-07-21 17:01:02 +02:00
4277561aa4
Reorder Vst3Bridge methods
2021-07-21 17:01:02 +02:00
418cd68a81
Resize the new wrapper window for VST2 plugins
2021-07-21 17:01:02 +02:00
42762d1abe
💥 Use another layer of editor embedding
...
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`.
2021-07-21 17:01:02 +02:00
75ab133adb
Change ProxyWindow into a more generic X11Window
2021-07-21 14:37:52 +02:00
a38e7c3588
Rename DeferredWindow to DeferredWin32Window
2021-07-21 14:26:34 +02:00
68d4a6610e
Don't reparent when the parent gets reparented
...
Some hosts, like Carla 2.3.1, will resize their windows to match the
reparented window's client area. This messes with our ConfigureNotify
setup.
2021-07-21 13:20:39 +02:00
1ee1229e47
Only show reparent message with editor tracing
2021-07-21 13:20:05 +02:00
acfceaa93f
Reuse the reparenting tracing in XEmbed
2021-07-20 23:13:23 +02:00
a749faa17f
Don't trace the start of every X11 event
...
We'll already print the event anyways.
2021-07-20 23:08:44 +02:00
ca6fc3a453
Fix typo in log message
2021-07-20 23:06:59 +02:00
ff76e482f2
Inhibit the event loop during VST3 editor init
...
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.
2021-07-20 16:24:25 +02:00
22be79aa0d
Move X11 event tracing behind +editor debug flag
2021-07-20 03:15:39 +02:00
db8eb5b678
Add a todo about the editor debug level
2021-07-20 01:31:24 +02:00
f2ffb68b55
Attempt to fix rare multiple displays issue
...
(cherry picked from 1950206159fbc830718803fa152b636b2a914a95)
Under certain DEs/WMs, the window might not render at all when using
multiple displays and the primary display is set to the rightmost
display.
This seems like a reasonably candidate for fixing this.
https://github.com/robbert-vdh/yabridge/issues/89
https://github.com/robbert-vdh/yabridge/issues/104
2021-07-20 01:10:31 +02:00
8fbc13fc25
Steal the window back when the WM reparents it
...
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.
2021-07-20 01:10:31 +02:00
0f75461379
Check the windows IDs when handling X11 events
...
This seems like a good idea now that we're listening to more and more
events.
2021-07-20 01:00:03 +02:00
906ead26fd
Perform some more diagnostics when reparent fails
2021-07-20 00:43:57 +02:00
ca883da5b2
Add tracing for the various X11 events
2021-07-19 12:59:16 +02:00
a02dcbdb5a
Fix an...interesting spelling correction
...
I might have accidentally hit `z=` at some point.
2021-07-18 19:48:16 +02:00
28ab46e3c1
Explicitly check for CF_HDROP
...
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.
2021-07-18 19:20:44 +02:00
4fc683188b
Use std::this_thread::sleep_for instead of usleep
...
This is a bit cleaner.
2021-07-18 14:14:23 +02:00
8c285688e8
Remove unnecessary function call
2021-07-17 22:57:50 +02:00
f43e9c2153
Only consider host windows with WM_STATE set
...
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.
2021-07-17 21:05:27 +02:00
b99f03cf64
Rename topmost_window to host_window
...
Since apparently to keep REAPER happy we shouldn't take the _very_
topmost window.
2021-07-17 19:11:29 +02:00
e4f2e8c27f
Add a separate audio thread mutual recursion stack
...
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)
2021-07-15 21:05:36 +02:00
1e0cf33eba
Use a recursive mutex for the Melda deadlock fix
...
This seems safer with the whole mutual recursion thing.
2021-07-15 16:01:47 +02:00
5f7fb2e2c3
Work around thread safety issue in Melda plugins
...
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.
2021-07-15 15:45:15 +02:00
f02341e77f
Fix focus handling when reopening REAPER FX 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.
2021-07-15 14:21:50 +02:00
0c816b0046
Only ignore -Wmaybe-uninitialized on GCC
...
An ifdef sounds like a better approach than ignoring two additional
warnings.
2021-07-14 17:18:44 +02:00
f292158889
Silence some more clangd warnings
2021-07-14 17:11:27 +02:00
8b870a51b0
Remove unnecessary XDND proxy call
...
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`.
2021-07-14 16:41:24 +02:00
764eb41da9
Remove fixme about Wine deleting windows twice
...
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.
2021-07-14 16:35:51 +02:00
591b2b9ceb
Also warn on version mismatch for VST2 plugins
2021-07-13 22:24:02 +02:00
5fc7acccd1
Show a notification on version mismatch
...
Between the plugin and the Wine plugin host application.
2021-07-13 22:14:31 +02:00
4013aea63a
Include the configuration as a dependency
...
Apparently this wasn't even supposed to work, so it's probably a good
idea to do it properly before things break.
2021-07-13 22:05:11 +02:00
d8215e4664
Allow cancelling the drag-and-drop with Escape
2021-07-12 22:58:24 +02:00
2ebefb1280
Send an escape key press instead of WM_QUIT
...
This should allow the drag-and-drop operation to quit gracefully.
2021-07-12 21:36:08 +02:00
bbb84cdf2c
Remove spurious drag-and-drop tracker WM_QUIT
...
We don't want to cancel the plugin's own drag-and-drop, oops.
2021-07-12 21:17:12 +02:00
96fb53be8f
Fix the CAS in the XDND check
...
Oops. We were doing the opposite of what we wanted, which caused the
first drag to always fail.
2021-07-12 14:00:48 +02:00
ad4fb1a0ec
Don't define X11 error throwing macro in DND proxy
...
We didn't need this after all because we don't integrate with the
editor's X11 event loop.
2021-07-12 13:35:10 +02:00
2f8bb7ef06
Only allow a single XDND operation at a time
...
MT-PowerDrumkit apparently cancels its drag-and-drop operations and then
immediately starts a new one.
2021-07-12 12:35:07 +02:00
a478436af6
Make sure the Windows dnd operation terminates
...
I've seen a weird edge case where this doesn't happen once, but i
haven't been able to reproduce it. Hopefully this fixes it.
2021-07-12 12:21:52 +02:00
11d3ec9010
Also change cursor with the last status message
...
The idea was that you wouldn't be able to see it anyways, but it feels
better this way.
2021-07-11 21:40:42 +02:00
4d74963e0a
Flush any spooled XDND messages
...
The last position change message would never reach REAPER under when
using certain plugins because we forgot the flush.
2021-07-11 21:35:39 +02:00
1b4c4ecfad
Remove old warning
2021-07-11 19:43:53 +02:00
c968a357f6
Fall back to HDROP with empty format enumerator
...
This happens with MeldaProduction plugins.
2021-07-11 19:29:15 +02:00
b1b47ec80d
Allow dragging to the right and bottom of plugins
2021-07-11 18:48:32 +02:00
ca5a7b2b96
Continue polling while LMB is held
...
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.
2021-07-11 18:34:26 +02:00
Robbert van der Helm