[ushiocheng]

What does this PR do?

Makes plugin editors open on Linux. In 1.4.0, pressing "Open editor" fails with:

window handle: the underlying window handle is not available

editor::open builds the host window with .visible(false) and then hands it to
embed_editor, which calls window_handle(). On Linux, tao returns
HandleError::Unavailable whenever the GTK window has no GdkWindow, and GTK only
creates that on realize, which a never-shown window has not been through. The
error is raised before the X11/Wayland check, so it also happens under XWayland.

The fix realizes the GTK window right after it is created, on Linux only, so the
native window exists by the time a plugin view is parented into it. If the GTK
window cannot be fetched, the editor window is closed and the error is returned.

Why is this the right approach?

Realizing creates the native window without mapping it, so the existing
hidden-until-embedded behaviour is kept: the window still appears only once the
plugin view is attached and sized.

Alternative considered: building the window visible on Linux. That works without
new code, but shows an empty fallback-sized window before the embed and flashes
one on a failed embed, which the current code deliberately avoids.

New dependency: gtk = "0.18", Linux-only. It is needed for WidgetExt::realize
on the window tauri returns from gtk_window(). It is the same gtk 0.18.2 that
tauri, tao and webkit2gtk already link, so Cargo.lock gains one line and no new
crates, versions or features. It does not enter the Windows or macOS dependency
graph.

Checklist

• Diff is limited to the change — no unrelated edits
• bun run check passes — not run; no frontend files are touched
• cargo check --manifest-path src-tauri/Cargo.toml passes — not run locally;
  a full tauri build --bundles deb passed on ubuntu-22.04 in my fork's CI
• bun run format leaves the tree clean — not run; rustfmt --check with the
  repo's rustfmt.toml is clean on the changed file
• Generated TS types are committed with the Rust change (none changed)
• No new dependency without a reason in the PR description
• This change adds nothing to cpal / SCK callbacks or DspWorker::run; it runs
  on the main thread when an editor window is opened

Platform coverage

• Developed on: Debian 13 (x86_64), GNOME on Wayland, PipeWire 1.4.2
• Tested on: Linux only, running Splitwave under XWayland (GDK_BACKEND=x11)
• What I did to test: built an unsigned .deb from this branch in fork CI, installed
  it over 1.4.0, routed System Audio through a VST3 plugin to a speaker, started
  the pipeline and pressed "Open editor". Before: the error above. After: the
  editor window opens and renders.
• Not tested: macOS, Windows, a native X11 session, a native Wayland session, and
  CLAP editors on Linux (same code path, but I had no CLAP plugin that passes the
  scan filter)

Per-OS files: none. The change is one #[cfg(target_os = "linux")] block in
src-tauri/src/audio/plugins/editor.rs; macOS and Windows compile the same code
as before.

🤖 Generated with Claude Code

[Horuse]

Thanks a lot for digging into this, and for the very clear write-up. The root cause analysis was spot on: the hidden window was never realized, so tao had no GdkWindow to hand out. Your fix does solve it under XWayland.

The catch is that it only works when the whole app runs on XWayland. On a native Wayland session GTK has no X11 window at all, so there is nothing to realize, and asking every user to launch with GDK_BACKEND=x11 (or forcing it on them) pushes the entire UI through XWayland just so plugin editors can open.

So I went a different way in #66: on Linux, editor windows are no longer GTK windows but plain X11 windows created with x11rb on XWayland. The main UI stays native Wayland, and only the plugin editors go through X11. Your investigation is what pointed me there, so thank you.

I'm going to close this one in favour of #66. If you get a chance to try it on your Debian/GNOME setup, especially with a native Wayland session and a CLAP plugin, that would be really helpful.

[ushiocheng]

No hard feelings. I like the tool and found a way to get it running on my machine. Appreciate your work.