v0.2.4 - the editor opens when you ask for it

A plugin GUI opens when you click the effect, not when the project loads. On the test project that is eight windows at load down to zero.

This release is made of a tester's list. Four of the items turned out to be one cause.

The bridge opened every editor because it thought Resolve never would

A comment in the source said that with the stock panel suppressed Resolve never calls InitializeEffectEdit, so there would be no other way to open a window at all. It does call it. One click on the effect in the Audio FX panel logs:

editor: shown (AudioPlugin::InitializeEffectEdit)

The reading that said otherwise watched the primary slot; the one that fires is the AudioPlugin base. With a real open signal, three reported problems go away together.

Every plugin GUI constructed during a project load is the worst thing this bridge did to a large project. FXBRIDGE_OPEN_ON_CLAIM=1 brings the old behaviour back if a machine turns out to need it.

A window that came back after you closed the modal. A hide arriving with our window already gone used to be re-read as a request to show it. A hide is a hide now.

A deleted effect could leave its GUI on screen. The pump closes the editor of any effect whose vtable pointer is no longer ours.

Editor windows behave like windows

They were _NET_WM_WINDOW_TYPE_UTILITY, chosen so a tiling layout would not claim them — and KWin excludes utility windows from the switcher by type, so no amount of window-state juggling would have brought them back. They are dialogs now: a tiling layout floats a dialog for the same reason, and KWin lists it.

Three things were missing outright, which is why an editor also never took the keyboard:

• WM_CLASS. A desktop environment labels a window by looking its class up in the installed desktop files, and a class of our own matched nothing, so KDE listed every editor as unknown. The class is Resolve's own now, which is also the honest description of what these windows are.
• WM_HINTS with input = True.
• An _NET_ACTIVE_WINDOW request, on the first map and on every reopen. A map alone leaves the window behind whatever you were on.

FXBRIDGE_WINDOW_TYPE accepts dialog (the default), utility and normal.

Unchanged from v0.2.3

Settings live in the Resolve project. See the v0.2.3 notes for what that does and what it still cannot do.

Install

See the readme. Every release and what changed in it is in CHANGELOG.md.

Not a supported product. It patches structures inside Resolve's process at run time and can take Resolve down mid-edit. Save often.

The binary

Built in an Ubuntu 20.04 rootfs, not on a current distribution. Floor GLIBC_2.16, CXXABI_1.3.9, GLIBCXX_3.4.22, and zero undefined symbols when checked inside that same old rootfs — which covers Ubuntu 18.04, Debian 9, Rocky 8 and Fedora 25 upward.

sha256  e499e71708fc8d5018a696fd9c41613aeaf176e17745413e7ae0f022a3ba58b1

That does not prove Resolve runs on a distribution that old. The bridge was tested there, the host application was not.

The build is scripted now: tools/release-sandbox.sh makes the rootfs, tools/release-build.sh v0.2.4 compiles the tag inside it and refuses to emit a binary with undefined symbols.