Plugin GUI: graft the editor's views onto a host-supplied window

bcox commented

2026-08-18 01:34:38 +00:00

Owner

The largest outstanding extension, and the reason preset transport had to be
built at all: the plugin has no GUI, so a host renders the generic parameter UI
over eight macro knobs, and a patch can only be authored in the standalone
editor.

The seam already exists and is deliberate. editor/BUILD.bazel states it:

What a patch edit is, and what may perform one, is separate from what draws
it: edit_sink and patch_document depend on neither ImGui nor a window.

The views do depend on ImGui, but on nothing that opens a window. That line
is where the plugin GUI would eventually be grafted on -- it would supply its
own EditSink and its own platform backend, and reuse these views unchanged.

So the work is not "write an editor UI" — that exists. It is:

Implement clap.gui in plugin/plugin.cc.
Supply a platform backend for the host-provided window, in place of
tools/patch_editor.cc's GLFW one.
Supply an EditSink whose patch is owned by the audio thread, where edits
must reach it without tearing and the host must be told about the ones it
considers parameters. See the companion issue on RequestMacro().

Why the seam is worth defending

It has already been defended once. During preset transport, editor/preset_browser
was given a dep on @imgui//:imgui_glfw_opengl3 — the GLFW+OpenGL backend —
where every other view target deps on plain @imgui. That would have made the
preset browser the first editor/ target that could not link into a
host-supplied window without dragging GLFW along. Caught in review and fixed in
6cae523.

Worth a build-level guard so it cannot regress: nothing under editor/ should
be able to depend on the ImGui backend target.

The largest outstanding extension, and the reason preset transport had to be built at all: the plugin has no GUI, so a host renders the generic parameter UI over eight macro knobs, and a patch can only be authored in the standalone editor. The seam already exists and is deliberate. `editor/BUILD.bazel` states it: > What a patch edit is, and what may perform one, is separate from what draws > it: edit_sink and patch_document depend on neither ImGui nor a window. > > The views do depend on ImGui, but on nothing that opens a window. That line > is where the plugin GUI would eventually be grafted on -- it would supply its > own EditSink and its own platform backend, and reuse these views unchanged. So the work is not "write an editor UI" — that exists. It is: 1. Implement `clap.gui` in `plugin/plugin.cc`. 2. Supply a platform backend for the host-provided window, in place of `tools/patch_editor.cc`'s GLFW one. 3. Supply an `EditSink` whose patch is owned by the audio thread, where edits must reach it without tearing and the host must be told about the ones it considers parameters. See the companion issue on `RequestMacro()`. ## Why the seam is worth defending It has already been defended once. During preset transport, `editor/preset_browser` was given a dep on `@imgui//:imgui_glfw_opengl3` — the GLFW+OpenGL *backend* — where every other view target deps on plain `@imgui`. That would have made the preset browser the first `editor/` target that could not link into a host-supplied window without dragging GLFW along. Caught in review and fixed in `6cae523`. Worth a build-level guard so it cannot regress: nothing under `editor/` should be able to depend on the ImGui backend target.