Hi.
In the AudioPluginHost example, compiled from the repository, most of the plugins which has UI displays out of their window, which itself remains glitched. As if the component was not well positionned. So there are a glitched window with its working title bar, and sometimes another floating window with the workable plugin UI elsewhere.
I tried to set off JUCE_USE_XRANDR, JUCE_USE_XSHM and JUCE_USE_XSHM in juce_gui_basics.h but it has no effect.
Please could you let us know:
That’s seems to be the window manager. It works with MATE.
Before asking I did only test xfce, Fluxbox and Gnome 
I tested on a laptop, with Debian 12 : with xfce it does it very rarely, but it does it sometimes.
It doesn’t seem to do it with MATE.
So maybe it does it very rarely with MATE too, if so I’ll tell here.
I’m on Debian 12, Linux 6.1.0-40-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.153-1 (2025-09-20) x86_64 GNU/Linux
I have a nVidia GeForce RTX4060, with the latest official driver, NVIDIA-Linux-x86_64-580.95.05
I tested to build the driver with the official modules and with the MIT/GPL, same results.
I use x11. I try to test with wayland but I haven’t still find how to activate it.
But the problem is here with Gnome on Xorg.
I repeat the problem :
When opening a plugin UI, first a window appears, and then the plugin UI appears,
and sometimes it’s not in the first window, like a component not well added. The first is then gliched. But the sizes always match.
Sometimes the two are glitched, sometimes there is only one. Even one time that crashed, when opening an UI (gxTuner, from Guitarix) :
AudioPluginHost: ../../../../src/cairo-error.c:68: _cairo_error: Assertion `_cairo_status_is_error (status)’ failed.
A few lines, diff of the results of xprop on each windows, but all seems normal.
$ diff with_UI_window other_window
0a1
> _NET_WM_ICON_GEOMETRY(CARDINAL) = 3900, 1034, 200, 23
2c3
< _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_STICK
---
> _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_STICK
6a8
> _NET_WM_STATE(ATOM) =
8,11c10,13
< user specified location: 0, 0
< user specified size: 1 by 1
< WM_ICON_NAME(UTF8_STRING) =
< WM_NAME(UTF8_STRING) =
---
> user specified location: 235, 96
> user specified size: 450 by 343
> WM_ICON_NAME(UTF8_STRING) = "ZamTube (LV2)"
> WM_NAME(UTF8_STRING) = "ZamTube (LV2)"
20d21
< _NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR
Thanks for the answer. And sorry, my question missed details indeed.
I’ve done more tests.
Interessant result : it works almost (always 2 windows, one in (0,0) with the UI) on Openbox but it doesn’t (the 2 windows glitched) on Fluxbox. It works on LXDE, which is based on Openbox.
It doesn’t do it at all with EXWM, a WM for Emacs, so no compositor, not border, etc. at all. But it does it when I start xfwm4 in.
So It seems to be a problem with the position of the window. Like a bad range. With WM where it doesn’t work, I get one time an assert from X11, about bad range for the position of the window.
I try to follow the flow in the JUCE code. In juce_LV2PluginFormat.cpp, in createView(), configuredEditor->getBounds() returns (0,0).
If useful I’ll redo tests and post these assertions.
It may be a problem with win position because : I have written a personal border for my windows, it uses getDistanceFromDragStart, getScreenPosition, setSize and setTopLeftPosition. It works well only in the WM where there is not the problem, that’s correlated. In the others, the drag gets crazy, there are jumps in getDistanceFromDragStart values, I’ll check this.
But there are some plugins which doesn’t work even on Openbox, EXWM or Mate, for example LV2-Sorcer. Got two windows, both are glitched. Btw an assert in juce_LV2PluginFormat.cpp:2618, jassert (widget != nullptr);
Note that there no problem, in every WM, with Carla, the plugin host of falktx.
I’ve debugged this a bit. I think I see the problems you’re describing with LV2 plugin hosting, and I’ve got a fix on the way. It might take a little while for this to reach develop, as it’s related to some other editor changes that I’m working on.
Are you only seeing the problems you describe with LV2 plugins, or do they affect other formats too? My potential fix only affects LV2, so it would be good to confirm that other formats work as expected.
In the case of the OpenAV Sorcer plugin, I think this plugin is buggy and needs to be fixed. There are two main problems:
The critical issue is that it does not implement the Xembed protocol correctly. JUCE asks the client window for its _XEMBED_INFO. According to the docs for Xembed, this property is made up of two 32-bit words, where the first word is the Xembed version (0), and the second word is a set of flags that the client can use to request that it is mapped or unmapped. If we look at the source for NTK, used to implement the UI for Sorcer, we can see that it gets these fields the wrong way round:
The effect of this is that the embedded window always reports that it doesn’t want to be mapped, so JUCE respects this request and doesn’t display the window. If I flip these two flags and rebuild ntk + Sorcer, then JUCE displays the UI.
The second issue is the cause of the jassert (widget != nullptr) assertion. The API documentation for the LV2 UI extension specifies that the widget parameter is an out-parameter, and that the client UI is responsible for assigning the address of the UI that it creates.
(output) widget pointer. The UI points this at its main widget, which has the type defined by the UI type in the data file.
If we look at the implementation of instantiate for Sorcer’s UI, it doesn’t appear to assign the widget pointer. This is an implementation bug in Sorcer.
Yes indeed it doesn’t do it with VST3 plugins.
LADSPA of course uses the generic UI which works.
Sorry for the delayed answer. Don’t know why I didn’t reveive a mail notification.
And thanks for the motivating demonstration of code crawling.
I noticed something maybe useful for debugging :
on the WM with the UI display problem, I can’t resize the main host window.
Only on Fluxbox I see and can drag a frame, but after mouse up that doesn’t resize.
And again it works on Mate.
–
But resizing works for the other ResizableWindows and Components that I addToDesktop. Seems to be only for the window created in PluginApp constructor.
It is marco which works. If I launch marco WM in every DM it works.
