Apologies if there’s already a thread about this, but I couldn’t spot one..
Just wondering if there’s been any thoughts by the team on the whole GTK event loop vs JUCE event loop situation on Linux.
I’m working on codebases where I’m mixing up JUCE and choc, and using choc webviews, and hitting problems in terms of which message loop needs to run.
For a GTK webview, the GTK one needs to be running, and I’ve got wrappers around that in choc to do messaging, timers, etc. But when there’s an JUCE GUI/event code running, the JUCE event loop needs pumping at the same time, and this is a total bodge.
In retrospect, I think it’d probably have made more sense if I’d used the GTK approach to JUCE’s event loop 25 years ago - has anyone considered a switch to that approach? There might be huge gotchas that I’m unaware of, I’ve not really looked into it.
In the meantime, the hack I’m using is to let JUCE launch my app, then in a callback on the (JUCE) event loop, I create a choc timer which dispatches the JUCE event loop every 10ms, and then enter the CHOC/GTK event loop for the rest of the app. This kind of works, but is nasty and probably inefficient, so am looking for better ideas..
No, I don’t think so. I can stick it on my backlog, but as a big disruptive change we’d only want to do this if there are clear benefits.
JUCE has a built-in GTK-backed webview. Could you use that directly? If not, maybe the implementation could provide some hints. IIRC we fork a new process for the webview and then XEmbed it back into the parent, which doesn’t spark joy but it does sidestep the message loop issues.
Another thought: I’m not super familiar with the GTK event loop, but there’s some functions in juce_EventLoop_linux.h that let you register an arbitrary file descriptor with a std::function callback that will be called whenever the file descriptor becomes ready. So, if there’s a way to grab an appropriate file descriptor and callback from GTK, then you might be able to install them both using this mechanism. That way, the JUCE and GTK messages will both get processed on the same thread.
I guess the benefit for JUCE would be when people start building plugins that use a webview and expect a GTK event loop, which won’t work in JUCE hosts currently.
I did have a quick look at the GTK backend for plugins, but it seemed to be basically the same thing I was doing with a timer + call to dispatch pending JUCE events.
I’m not sure that’s a reasonable expectation for plugins, though. in the case of VST3, plugins access the host message loop using a file-descriptor-based mechanism similar to the one described above. The plugin isn’t supposed to make assumptions about who/what is driving the event loop. i.e. I think it’s up to the plugin to make its event loop work in the context of the host, not the other way round.
I’m pretty sure the JUCE WebViewPluginDemo works in arbitrary hosts on Linux - I’d start there (and, please let us know if you find a host where it doesn’t work as expected!).
