Priority Request: UXP Hybrid Plugin support in InDesign

InDesign
, ,
1

While I’m aware that UXP Hybrid Plugins (C++) is on the roadmap for InDesign development, it sounds like this is still a ways off. I decided to start a topic to gather some of the main reasons I believe this should be top-priority for the InDesign team as this is preventing a lot of teams from migrating from CEP extensions to UXP plugins or from C++ plugins to UXP plugins.

Reason #1: CLI Access

A few months ago, we released Bolt UXP, a framework for accelerating UXP development, and while Bolt ships with templates and pre-signed binaries for UXP Hybrid plugins, these only work in Photoshop currently, not InDesign. One of the big reasons we ship this Hybrid Plugin option is for the execSync() function, which gives developers access to the command line like Node.js did in CEP panels, since UXP does not expose this. ( more on the evolution of this request from my initial request for CLI access back in 2019 )

Why is CLI access important for extensions/plugins? Lots of our tools rely on standalone binaries such as FFMPEG/Jimp/OpenCV to achieve tasks not possible in native plugin languages. Additionally, many developers opt to store their licensing frameworks in an external binary for security. Without CLI access of some sort, countless tools simply cannot be ported to UXP.

In Photoshop we were able to build a workaround for this with UXP Hybrid Plugins, but since Hybrid Plugins are not yet in InDesign, developers building for InDesign cannot take advantage of this workaround yet.

Reason #2: App C++ APIs

Many developers have opted for building C++ plugins rather than CEP extensions / ExtendScript scripts simply because certain API Methods only existed in the C++ APIs and not in the JS APIs. UXP Hybrid Plugins however has a nice solution for this, in that we can opt to build our plugin logic and UI in JavaScript, and reach out to C++ in a Hybrid Plugin to access these APIs, getting the best of both worlds: the speed of development from JavaScript, and the full flexibility of C++ and an app’s C++ APIs.

This is currently possible in Photoshop, but again not yet in InDesign as Hybrid Plugins are still pending.

Reason #3: C++ Only Functions

Finally, certain functions such as computationally heavy tasks make much more sense to accomplish in a lower level language like C++, rather than a higher level language like JavaScript.

This is one of the main advertised features of UXP Hybrid Plugins, yet again isn’t yet available in InDesign.

Summary

This conversation has been on-going for some time, but was recently sparked after speaking with InDesign developers at CreativePro Week’s Creative Developer Summit 2024. While many dev teams are interested in migrating to UXP and would like to take advantage of the benefits of a JavaScript UI with a C++ backend via UXP Hybrid Plugins, migration to UXP simply isn’t an option until C++ Hybrid Plugin capabilities are implemented for the reasons mentioned.

To the Adobe InDesign Team:
I would highly recommend bumping UXP Hybrid Plugins priority to top of the list in order to get faster and more widespread adoption from the developer community.

To InDesign Plugin Developers:
If you have project examples to add to the conversation, please share below to further illustrate why UXP Hybrid plugins are a requirement for migration in many scenarios.

5 Likes
2

I can’t emphasize just how right Justin’s arguments are here.

Please, InDesign team, give us hybrid plugins.

We can’t adapt our whole suite of popular data publishing C++ plugins to use UXP for UI until this happens.

And we have some big plans that are on hold until this happens.

3 Likes
3

For @cpryland and many like him, hybrids are crucial.

I am praying that UXP doesn’t come to Illustrator without hybrids.
For other cases that @justin2taylor mentioned there could be some workarounds.
I have not tried either of these on UXP maybe these work on UXP too?
app.doScript("code or file path here", ScriptLanguage.VISUAL_BASIC)
app.doScript("code or file path here", ScriptLanguage. APPLESCRIPT_LANGUAGE)
You can then get the result from the C++ code.
I.e. using VBS or Apple Script call the C++ code (FFMPEG) and send the result to the regular scripting engine.

You can also use new ExternalObject("Path to binary") to run external binaries.
Please don’t ask me for details on that one.

The workarounds are only valid for InDesign and only for calling external code including CLI processes. They are useless for DOM control of the host app which is what hybrids are about.
Developers like Chris have invested a fortune of time and money in developing CEP - C++ hybrids and are now in a state of limbo after just a few years of CEP being around, waiting for the next “new thing” to catch up.

1 Like
4

It’s important for Teacup as well to have hybrid plug-ins for InDesign. We’ll hold off on some of our work as well waiting for this.

Thanks guys!

Lawrence

1 Like
5

There’s another kind of “hybrid” plug-in, too–a C++ plug-in that extends InDesign’s scripting DOM (because you can do that with InDesign). The UXP side then uses the new objects/methods/properties exposed by the plug-in.

We (SPI) already do this, and I think it works fairly well. I just wanted to mention it as another case.

[Edit: This sort of falls under " Reason #2: App C++ APIs"–except that the C++ plug-in is adding scripting commands that can be used by JavaScript, rather than using some other approach. In my opinion, all C++ plug-ins in InDesign should provide scripting support for whatever they do.]

Thanks,

Ole

1 Like
6

Great options to point out. There are indeed a few ways to run C++ plugins / functions from ExtendScript with app.DoScript() or ExternalObject(), but with the goal of migrating to UXP for the modern JS stack + improved UI on the frontend, this doesn’t fit the long-term goal to migrate to UXP, but would keep devs working in ExtendScript.

7

Very interesting, thanks for adding your experience here!

We’ve done something similar in After Effects in the past, calling ExtendScript from C++ plugins for certain instances, but this mainly worked for the case where the tool needed to be a C++ plugin and we just needed a specific ExtendScript function for a method that wasn’t exposed in the C++ API.

The second part of your post seemed to describe a partial-UXP-hybrid plugin of sorts. Am I understanding correctly that you essentially ship a regular UXP plugin and a regular C++ plugin and have some sort of communication channels between the two? If so, just had two follow up questions on setting this up:

    1. Install Process: Is a custom installer required for this to install the UXP panel with UPIA and the plugin to it’s own os-specific folder?
    1. Since CLI access isn’t exposed in UXP, are you communicating via HTTP / WebSocket / or some similar approach between the two plugins?
8

The question is, if app.doScript() and ExternalObject() are available on UXP without going through ExtendScript.
I don’t know where or not they are exposed to UXP’s API

9

Not that I’m aware of in any UXP implementation, but I think this would be a good request for a new issue. That could really help with migration if we can still use some older APIs while we wait for the new ones to be built…

1 Like
10

Hi Justin,

I’m not sure if you can extend the DOM in After Effects…?

First, when I say “plug-in”, below, it includes InDesign native features, as well as 3rd party plug-ins. InDesign itself is nothing but a collection of plug-ins.

There are no cases in InDesign where an ExtendScript function isn’t exposed in the C++ API. (Or there shouldn’t be–it’s always possible.) Scripting is built into every plug-in function that can touch the document–it’s not added on, after the fact, as it is in most other apps. On the other hand, there are some C++ functions that aren’t supported in scripting, so we add support for those, as well as adding entirely new functions.

As far as communication goes–it’s just InDesign scripting. The objects/methods/functions added by our plug-ins are merged into the InDesign DOM at startup as first-class citizens. They even appear in UXP. The other benefit is that objects/properties added to a document by the plug-in will be supported in .idml/.idms (InDesign’s interchange formats). (I’ll admit that I’m proud to have been involved in the development of InDesign scripting.)

re: Install Process–yes, I’m pretty sure these have to be custom installers. I have to check with the installer guys to be sure, but I think we’re still using the approach we took with CEP extensions–the CEP parts go the OS-mandated places; the C++ plug-ins go to the InDesign Plug-Ins folder.

re: CLI access–I don’t know that we’ve done this with UXP plug-ins, to date. For CEP, we used a mix of approaches. We’ve also used InDesign’s app.doScript() to run AppleScripts and VBScripts, as needed.

For better or worse, a lot of our work requires XML, so those parts will stay in ExtendScript as long as possible–E4X is superior to anything “modern” JavaScript has to offer (that I know of). Telling large corporations to “just use JSON” doesn’t work very well.:slight_smile:

Also, we work with .idml/.idms extensively, and those are XML formats. In some cases, we serialize these into JSON, depending on what we need to do.

Thanks,

Ole