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.
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 still really curious why this double reparent would be needed
though. Everything works fine on any other i3 config I've tried, and
even the exact same config in a VM works fine for me.
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.
These things should not fail (and I've never seen one of these thing
error out with yabridge), but in the case they do an assertion is at
least a lot trace down than a segfault.
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.
Also remove any special `effEditIdle` handling.
Apparently plugins rely on the message loop for their internal tasks,
even for things that have nothing to do with GUIs, such as deferring
initialization.
This was mostly a workaround to get Serum to not crash when audio was
being processed during a specific point of its `WM_PAINT` message
handler. This is no longer needed when using `CreateThread` instead of
`std::thread`.
Robbert van der Helm