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.
Apparently X11 connections are a scarce resource, so it seems like a
good idea to not hang on to them for too long. Now this is sort of a
hybrid between COM-style memory management and a singleton.
We did this before implementing the deferred close in yabridge 3.0.0. It
didn't seem necessary anymore so we got rid of it, but without this
closing an iZotope Rx plugin's editor in Renoise was guaranteed to
trigger an X11 error and crash Renoise. Doing this reparent doesn't seem
to cause any slowdown but it does at least fix the specific combination
of iZotope Rx and Renoise.
It's pretty hard to find a solution that checks all of the boxes. I want
something that:
- Closes instantly when you close the editor, and in REAPER you should
be able to instantly switch between docked and floating modes
- Where there should not be a delay in user interaction when quickly
reopening the editor (or doing that switching thing in REAPER since that's
the same thing)
- Where the window manager should not try to reparent the window during
the losing process as that can cause some jarring flickering
- And, of course, there should be no weird Wine X11Drv crashes
And it should do all of that in Bitwig, REAPER, Carla, Ardour and
Renoise. Apparently it's quite the task to find an approach that checks
all the boxes there.
Although it hasn't shown up, this will get rid of the possibility of
off-thread effEditIdle calls causing issues. And since we need some way
to run call this function while the event loop is running anyways, doing
it entirely from a timer similar to how hosts on Windows would do it
seems like the best solution.
I've also tried a lot of other things, but none of the solutions I've
tried work 100% of the time. It sounds like a better idea to have
something that doesn't work consistently than to have something that
inconsistently sort of works. Setting the size in `WM_WINDOWPOSCHANGING`
to (0, 0) fixes the drifting, but the mouse coordinates are still wrong
and `SetWindowPos()` breaks the reparenting.
This reverts commit db2cc5800a.
I think some rounding in Wine is causing this issue, but then again
we're not supposed to send these ConfigureNotify events to the window
directly anyways.
This took me a few hours of non-stop headaches to figure out. Apparently
deep inside of Wine's headers having __MINGW32__ defined will cause some
GUIDs to be defined slightly differently. This normally wouldn't cause
issues, but when including `shellobj.h` or `objbase.h` this results in
multiple definition linking errors that are basically impossible to
diagnose.
There were already similar warnings on 32-bit winegcc, but now it also
happens on the 64-bit version. Instead of adding
`-Wno-ignored-attributes` we'll just sprinkle some warning ignores here
and there to prevent any other surprises.
I'm not sure how many people use WMs that don't implement
`_NET_ACTIVE_WINDOW`, but at least this will give those people some way
to grab input focus, even if it's not as good as the new method.
This fixes keyboard focus not returning when closing dialogs in Melda
plugins. I'll have to do some more testing to see if this does not
introduce any unwanted side effects.
This works around Waves plugins causing an infinite message loop. Since
we run the loop 30 times per second anyways splitting the loop up into
chunks of 20 shouldn't be an issue.
This sounds like it would the simplest way to work around the issue of
E27 calculating its own coordinates based on the parent window's
coordinates. I have not noticed any weird issues with having this
enabled all the time, but less moving parts is always better so it's
still behind an option.
Robbert van der Helm