setPopupDisplayEnabled broken in Linux

I noticed this just now, setPopupDisplayEnabled seems to be broken on Linux.

I haven't tested other OSes. Not sure when this started happening.


The popup is displayed based on 0,0 position instead of actual plugin pos.

See this to understand:


When the slider is pressed down this also happens:

JUCE Assertion failure in juce_DropShadowEffect.cpp:48


Any hints?



The code for this UI is here:

actually, it seems that all popups in linux are currently broken: :(

I get the same behaviour in my own plugin host and renoise.


I tested it with the Demo Host, the same thing kinda happens too.

It draws the popups at the proper initial position, but when the plugin ui is moved that position remains the same.


Everything seems fine in the JuceDemo app.


Can someone please confirm this with latest juce git?

this seems to be caused by this commit:


reverting that change makes popups work properly again.


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!

There's a reason why the old code was the way it was.

It's not optimal, but it does work.

Only juce-based hosts have issues loading those "old" plugins.


Also, resizing of vst windows got broken with that change too.

I think it's better to revert that commit until we find a proper fix.

I'm not going to revert the commit, because there's nothing wrong with it - the issue it fixes was described here:

Like I explained above, there just needs to be an extra callback so that as a child window it still updates its screen position correctly. 

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

    Point<float> localToGlobal (Point<float> relativePosition) override
        return relativePosition + bounds.getPosition().toFloat();

    Point<float> globalToLocal (Point<float> screenPosition) override
        return screenPosition - bounds.getPosition().toFloat();

This ensures that calls to the ComponentPeer pertaining to co-ordinate conversion will always use the correct bounds.

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.

    Point<float> localToGlobal (Point<float> relativePosition) override
        if (parentWindow != 0)
        return relativePosition + bounds.getPosition().toFloat();

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.

The size was never an issue, but pop-ups not appearing on the right place.