That commit fixes a bug whereby the plugin windows weren't actually being added to the parent window correctly! Reverting it is definitely not the right fix for what you're seeing!
Presumably the real problem is that because the plugin windows are now child windows of the host window, then when the host window is moved, the Windows aren't getting told about this, so they don't update their screen positions. There's a method LinuxComponentPeer::updateWindowBounds which needs to be called to keep this up to date, but I'm not sure what events to arrive that it could use to call this.. As I don't have a linux plugin system to debug this myself, I'd rely on you guys to help with clues on how to sort this one out!
I've taken a quick look into this, and it doesn't appear that any XEvents are received when a plug-in's UI is moved.
I did, however, find a solution. It's not elegant, but it does solve the detatched pop-up issue: replace localToGlobal and globalToLocal in juce_linux_Windowing.cpp with
That'd be too much of a performance-drain in such a commonly used function, but since IIRC the plugin windows are child-windows, how about making it conditional on it having a parent, e.g.
Afraid not: parentWindow is 0 for a Linux VST plug-in's UI. The parentWindow is never set because the previous change means we no longer call XReparentWindow.
Another observation: using the near tip of JUCE (a few days old), I tried the JuceDemoPlugin and Plug-in Host, 32-bit Ubuntu, reverted the XReparentWindow change, and tried to reproduce Rory's issue. And I couldn't. Maybe some other change since then has corrected it, but it appears that the original issue is no longer an issue. I opened and closed the JuceDemoPlugin's UI about thirty times, and it always opened at the expected size.