EmbedExternalUI in develop

[rorywalsh]

Hello everyone. I'm interested in testing the webview stuff on Linux but when I try the EmbedExternalUI example I only see a blank screen in Reaper? Any ideas what might be the problem? I'm running Ubuntu 24.04..

[falkTX]

that example runs an external tool for testing, for webview you want to check https://github.com/DISTRHO/DPF/tree/develop/examples/WebMeters instead.

if you have a real usecase for the webview I would be very happy to collaborate on it, on the parts that dpf needs handling.
so far that is the biggest blocker from moving the webview forward, I dont have a real plugin to do a real stress-test with.

[rorywalsh]

Whoops, thanks Filipe! I just tried the webmeters one now however, and this is what I see:

Closing and reopening doesn't seem to make any difference. I also passed through some audio in the hope it would repaint itself, but no luck.

[falkTX]

is that on linux? running via CLI would help to understand where it is failing

[rorywalsh]

Ok, it was a package issue. I had libwebkit2gtk-4.1 installed, and it was looking for libwebkit2gtk-4.0. It's working now. Sorry for the noise!

[falkTX]

it needs to support both, I dont want users to have to install extra things to get this working.
let me do a little change there then...

[rorywalsh]

I'm rewriting Cabbage so it no longer uses JUCE. I started using iPlug2 because it had an out-of-the-box solution for using webviews - but no support on Linux, hence I'm currently re-evaluating its use.

[falkTX]

might be fixed with cd18a7b please try, I dont have a distro with that lib to test here

[rorywalsh]

I purged libwebkit2gtk-4.0 and tried again, this time it loads fine. Thanks again. I need to see how this all works, now that I know it does ;)

[falkTX]

nice! maybe then we just keep this issue open for such communication.

so far the current implementation expects a plugin format that can do "bundles", so lv2, vst3 and AU.
for vst2 and clap you can use

CLAP_BUNDLE = true
VST2_BUNDLE = true

before including the plugin mk file.
this is not supported under cmake for the time being.

inside the plugin bundle needs to be an "index.html" file, which is loaded by default.

for JS side, the same DPF UI API is used, so you can call setParameterValue(index, value) from JS. and for receiving events just declare functions like function parameterChanged(index, value) {} on the global scope.

[rorywalsh]

Thanks Filipe. I'm just trying to figure out how I can evaluate arbitrary JS code from my plugin. It seems that the underlying web view object is not exposed? In my current build of Cabbage3, I can update the webUI from my Csound code. I have an OnIdle() method in my main plugin class that checks for updates from opcodes. If updates are found, it sends a JSON string to the webUI. Is this kind of thing possible here?

[falkTX]

that is intentionally not allowed, as it would bypass the host which we do not want to do in DPF.
you can have "states" which are key-value pairs of values, saved automatically when a specific state key is part of the defined plugin states.
arbitrarily send messages from UI to DSP and vice-versa is not supported on the default webview UI implementation.

you can though, alternatively, define your UI to be of generic type (cairo, opengl or "stub" for dummy no graphics mode) and then directly use the webview C++ APIs, see https://github.com/DISTRHO/DPF/blob/develop/distrho/extra/WebViewImpl.hpp
but in this approach you have to manage the whole C++ UI -> JS UI (and back) communication yourself.

[rorywalsh]

Thanks, I'll keep digging around. It's a very nice framework you've created here :)

[rorywalsh]

Btw, is the webview here created as a separate process? I'm trying to get my head around how this is implemented. It looks far more complicated that I had imagined 😬

[falkTX]

The Linux one is the most complex of the bunch, because (unlike other plugin frameworks) we really do not want to load gtk or Qt symbols into the global namespace, so a fork for new process is needed.
On Linux + X11, IPC using shared memory + semaphores is used to keep things in sync.

Also unlike other frameworks, DPF is not relying purely on gtk webkit, Qt WebEngine is also an option (both Qt5 and Qt6). That makes it work on KDE based distros too, without needing extra deps.

To top it all off, no external binary (to start web process) is used, everything is self-contained. DPF executes the linux ld-loader that runs the plugin shared lib as executable, or just the binary itself if standalone.

So yes, the behind the scenes is complex, but I try my best to abstract all that away. Also the complexity on Linux is just the way I see for making things proper, I don't want the lazy solutions like relying only on gtk3. Linux is the main target for DPF, so I go the extra mile for it.

[rorywalsh]

It took me a while to grasp what you were doing 🤣 But it's a neat solution, especially considering you don't need a separate binary. Nice.