Update: After further analysis the issue only appears when trying to host a JUCE 6 based plugin (here: Dexed) into HostPluginDemo from JUCE 7 as explained below.
Which version of Dexed are you using for testing? As far as I can tell, Dexed 0.9.6 was using JUCE 6, which didn’t have very good support for the event loop on Linux. I expect that you might see crashes due to threading issues, or due to undelivered messages in this case. I tested the current master branch of Dexed (0.9.7 - development), which uses JUCE 7.0.1, and that seems to run as expected in the HostPluginDemo in REAPER 6.79 on Fedora 38/Gnome. As a first step, I recommend making sure that you’re using the most recent version of Dexed and testing again.
Have you tested the plugin in any other plugin-hosting-plugins? It could be that Dexed itself doesn’t cope with being hosted in this way. To determine whether the issue is in Dexed or in the HostPluginDemo, you could try hosting Dexed inside Carla (or another similar host-plugin) and see whether that works as you’d expect.
How is your Linux machine configured? What window manager, graphics card + driver, processor architecture etc. are you using for testing?
Have you tried running REAPER/HostPluginDemo/Dexed under a debugger? If so, do you get an informative stack trace at the point of the crash?
For the DocumentWindow assertion, you can go and look at line 173 of DocumentWindow.cpp - there’s an informative comment that explains what’s gone wrong, and how you should implement the close button functionality.
Thanks @reuk. Turns out that your analysis is spot on. Switching to the latest Dexed NIGHTLY (2c03631) (which is using JUCE 7) solved the “mysterious” crashes when being loaded into HostPluginDemo (from JUCE 7). I had been using the latest Dexed release (0.9.6) (which is using JUCE 6) before.
I am really happy now, since not only HostPluginDemo is no longer crashing, but also my own plugin host VST that suddenly started to behave properly.
(Based on what I had seen, I was suspecting some threading issues, but I was always assuming the mistakes were in my code and not in JUCE 6 based Dexed 0.9.6.)
So thanks a lot for taking the time to test this and giving me the hint that actually the issue is with Dexed 0.9.6.
Again, thanks for the hint.
Coming from frameworks like Qt, it seems a bit strange for me that something essential like a window close button doesn’t “just work” and one has to follow assertion errors leading to comments in the source code of the framework.
void DocumentWindow::closeButtonPressed()
{
/* If you've got a close button, you have to override this method to get
rid of your window!
If the window is just a pop-up, you should override this method and make
it delete the window in whatever way is appropriate for your app. E.g. you
might just want to call "delete this".
If your app is centred around this window such that the whole app should quit when
the window is closed, then you will probably want to use this method as an opportunity
to call JUCEApplicationBase::quit(), and leave the window to be deleted later by your
JUCEApplicationBase::shutdown() method. (Doing it this way means that your window will
still get cleaned-up if the app is quit by some other means (e.g. a cmd-Q on the mac
or closing it via the taskbar icon on Windows).
*/
jassertfalse;
}
So it seems that I need to override the DocumentWindow::closeButtonPressed method.
So far I am creating a window using auto window = std::make_unique<juce::DocumentWindow> ("Dexed", bg, juce::DocumentWindow::allButtons);. It is not clear to me how I could override the closeButtonPressed without having to subclass DocumentWindow. Is there an example for this somewhere?